nascheme@users.sourceforge.net wrote: > Update of /cvsroot/python/python/dist/src/Misc > In directory sc8-pr-cvs1:/tmp/cvs-serv10115/Misc > > Modified Files: > NEWS > Log Message: > If a float is passed where a int is expected, issue a DeprecationWarning > instead of raising a TypeError. Closes #660144 (again). > > ! - The PyArg_Parse functions now issue a DeprecationWarning if a float > ! argument is provided when an integer is specified (this affects the 'b', > ! 'B', 'h', 'H', 'i', and 'l' codes). Future versions of Python will > ! raise a TypeError. I must have missed something (again). Where was this discussed in public ? I've read a quote from Guido on the SF tracker: """ This is an age-old problem that crops up whenever "i" and similar format codes are used. The problem is that on the one hand you want "i" to accept other int-ish types that have an __int__ method. But on the other hand you don't want it to accept float, which also has an __int__ method. Or other float-ish types. I think the "i" format code has to be fixed, but I'm not sure how -- maybe as a start it would be sufficient to test explicitly for float and its subclasses and reject those. That would still allow 3rd party float-ish classes that implement __int__, but that's not so important. """ I tend to *not* go conform with this opinion. If a type implements __int__ then it should be accepted whereever "i" is used. If the type feels that this usage is not ideal, then the *type* should issue the warning or TypeError, not the getargs.c implementation. Apart from this, the change is going to break tons of code, once the TypeError is enforced and due to the dynamic nature of Python a single release cycle will not be enough to catch all places where an explicit int() would be required... Which makes me think: int() started to return longs a few months ago -- we don't even have a cast which would raise an OverlfowError in case the conversion to int is not possible. Of course, int() would return a long and then the "i" parser marker implementation would complain, but that may be too late, e.g. in the case where you pass the data over the wire or store it in a file for later processing. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/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