[Tim]
>> PyLong_FromString() only sees the starting
>> address, and-- as it always does --parses until it hits a character
>> that doesn't make sense for the input base.
[Greg Ewing]
> This is the bug, then. long() shouldn't be using
> PyLong_FromString() to convert its argument, but
> something that takes an address and a size. (Is
> there a PyLong_FromStringAndSize()? If not, there
> should be.)
Yes, that's what I said ;-):
The internal parsing APIs don't currently support the buffer's "offset &
length" view of the world, so have no chance of working as hoped
with any kind of buffer object now.
Note that this isn't limited to long(): _no_ internal parsing routine
has a "sliceish" API now, and none of the code on the way toward
calling parsing routines is paying any attention to that it can't work
when handed a buffer object. All of that must change. At least the
complex() constructor gives up at once:
>>> b = buffer("123a", 0, 3)
>>> long(b)
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
ValueError: invalid literal for long() with base 10: '123a'
>>> int(b)
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
ValueError: invalid literal for int() with base 10: '123a'
>>> float(b)
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
ValueError: invalid literal for float(): 123a
>>> complex(b)
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
TypeError: complex() argument must be a string or a number
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4