> This is why "integer" is a better name than "baseinteger". > For now it can be the common supertype of int and long. > In the future, it can be the name of the single integer > type. No, that will be int, of course! Like 'basestring', 'baseinteger' is intentionally cumbersome, because it is only the base class of all *built-in* integral types. Note that UserString is *not* subclassing basestring, and likewise if you wrote an integer-like class from scratch it should not inherit from baseinteger. Code testing for these types is interested in knowing whether something is a member of one of the *built-in* types, which is often needed because other built-in operations (e.g. many extension modules) only handle the built-in types. If you want to test for integer-like or string-like behavior, you won't be able to use isinstance(), but instead you'll have to check for the presence of certain methods. I know this is not easy in the case of integers, but I don't want to start requiring inheritance from a marker base type now. Python is built on duck typing. (Google for it.) --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