[Tim, blissfully minimizes the difficulties of erasing the int/long distinction] [Andrew Kuchling] > Not quite *that* simple; you'd also have to change various bits of the > core that currently do PyInt_Check(whatever) to also accept longs. I had in mind a vague scheme to cheat. I have since recovered from the delusions. > I just sent off a patch to make long*sequence legal, but there's > still slicing and indexing to take care of: list[0L:5L] isn't > currently legal. Note that MS has already decided to leave sizeof(long) == 4 in 64-bit Windows, but sizeof(void*) will jump to 8. Python is remarkably free of dubious assumptions here, but, as you point out for Solaris, "large" files are likely going to make problems here on an increasing # of platforms. > The Solaris large-file patch that makes .tell() return a long is > probably going to turn up more errors like this. Making ints and long > ints integerchangeable would be an *excellent* idea. Possible for > 1.6? Maybe, if GvR indicates it should be a priority. 'grep -l > PyInt_Check' over the Python source code lists lots of Modules, most > of the files in Objects/, and 5 files in Python/ (ceval, marshal, > pythonrun, structmember, and traceback). The idea is very old, and has come up several times, but I don't recall Guido ever saying anything about it. So it's safe to conclude it *hasn't* been a priority for him. I can't channel him on this issue. I'm personally in favor of merging them, but along with Konrad (Hinsen) am also in favor of doing a lot more "numeric merging" in Python 3000. It's really unclear to me whether the distinction in Python1 can be erased without breaking programs -- but can't make time to think about it now, either. Sorry!
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