FWIW, I propose that in py3k, the int type uses Py_ssize_t instead of long. Already decided is that in py3k, the (x)range object will support arbitrary integer sizes, so that e.g. range(10**10, 10**10+10) is valid (it currently is, but for different reasons, it isn't with xrange, which will replace range in py3k). For 2.6 and onwards, I propose to let the issue rest *or* eventually backport the py3k xrange implementation; "fixing" xrange to use Py_ssize_t doesn't seem worth the churn. -- --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