> I would like to urge caution before making this change. Despite > what the PEP may say, I actually think that creating a 'baseint' > type is the WRONG design choice for the long term. I envision > an eventual Python which has just one type, called 'int'. The > fact that an efficient implementation is used when the ints > are small and an arbitrary-precision version when they get too > big would be hidden from the user by automatic promotion of > overflow. (By "hidden" I mean the user doesn't need to care, not > that they can't find out if they want to.) We are almost there > already, but if people start coding to 'baseinteger' it takes > us down a different path entirely. 'basestring' is a completely > different issue -- there will always be a need for both unicode > and 8-bit-strings as separate types. Not so sure. I expect that, like Jython and IronPython, Python 3000 will use unicode for strings, and have a separate mutable byte array for 8-bit bytes. In Python 3000 I expect that indeed somehow the existence of long is completely hidden from the user, but that's a long time away, and until then baseinteger might be a better solution than requiring people to write isinstance(x, (int, long)). --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