I've just posted a new patch set to the patches list which
contains better support for Unicode in the int(), long(),
float() and complex() builtins.
There are some new APIs now which can be used by extension
writer to convert from Unicode to integers, floats and longs.
These APIs are fully Unicode aware, meaning that you can
also pass them any Unicode characters with decimal mappings,
not only the standard ASCII '0'-'9' ones.
One thing I noticed, which needs some discussion:
There are two separate APIs which convert long string literals
to long objects: PyNumber_Long() and PyLong_FromString().
The first applies the same error checking as does the
PyInt_FromString() API, while the latter does not apply
this check...
Question is: shouldn't the check for truncated
data ("9.5" -> 9L) be moved into PyLong_FromString() ?
BTW, should I also post patches to string.py which use the
simplified versions for string.ato?() I posted a few days ago ?
--
Marc-Andre Lemburg
______________________________________________________________________
Business: http://www.lemburg.com/
Python Pages: http://www.lemburg.com/python/
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