> I was trying to suggest a parser marker for "accept whole > numbers only", ie. floats without fraction, integers, subclasses > of integers and other classes implementating __int__. I'm still against that, for the reasons stated here: > > Smarter people than you and me can disagree about that. Personally, I > > think that accepting floats with int values here is asking for > > trouble: a calculation that returns a perfect int on one machine may > > not do so on another, and hence a subtle portability problem is born. > > True. I was thinking of cases where some external lib > returns floats even for integers (e.g. database interface > which return DECIMAL columns with scale 0 as floats -- > Zope converts these to integers; even though these can > overflow). Now, you'll never see a float coming out of > that interface with a non-0 fraction. With the change you'll > also won't be able to pass the value as parameter to many > thousand Python APIs anymore. > > To work around this, the interface would have to be changed > to apply a magic similar to the one Zope uses. But then > you have a different problem: a change in data type based > on a database type parameter. This seems the burden of the database user in either case. Trying to compensate for this everywhere else in the language is wrong. > Python 2.3a1: > >>> int(123478987123L) > 123478987123L > > Now, if I want to make sure that I can pass the value to > "i" I'll have to add another check which makes sure that > the int() return value is indeed a standard integer. YADWTM (You Are Definitely Worrying Too Much :-). --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