> I must have missed something (again). Where was this discussed in > public ? The problem (and my opinion) has come up here on and off many times. > 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. Since all the type knows is that it's __int__ method is called, not that this is in the context of getargs.c, how could it protest in this case without protesting about all calls to int()? The problem is really with the semantic definition of int(). There should have been two different functions: one to convert an int from some other representation to a real int, and one to truncate a float or similar number to an int, losing information. (The latter actually requires several, or a way to specify the rounding mode. Unfortunately round() and math.floor()/ceil() can't be used since these return floats themselves.) Fixing this would require a much larger change to the language, with much more backwards incompatibilities to worry about; changing "i" etc. to explicitly refuse float is a band-aid that catches most of the cases. By far the majority of types that implement __int__ represent int-like data; only floats and rationals use __int__ for losing information. That's why the above solution was chosen. > 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... We'll change to a TypeError when we are confident that it won't break too much code. Why do you think so much will break? In Python 2.2, you can write a = range(10) a.insert(3.14, 0) and it will insert a 0 at position 3. This is undocumented. Do you really think anyone in the world willfully uses this? > 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. Why would you need one (except in C code, where "i" is such a cast)? In the future, the difference between int and long will disappear completely. > 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. YAGNI. --Guido van Rossum (home page: http://www.python.org/~guido/)
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