[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 _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com