[Guido] > I'm not sure I want to make this a priority given the accellerated 1.6 > schedule, but I certainly think this is the way of the future, and I > don't expect many backwards compatibility problems... I think more than one issue is on the table here: 1. Whether internal implementation code that currently relies on PyInt_Check should be liberalized to allow "int-sized longs" too. 2. Whether Python language semantics should be changed, so that e.g. int * int never overflows, but returns a long when appropriate. I was mostly talking about #2 but I think Andrew's enthusiastic agreement was really wrt #1. You may also believe I was talking about #1. Regardless, *just* tackling #1 at this time would be a good foundation for later decisions about #2, and has real value on its own (with, I agree, few backward-compatibility implications, and likely none serious (people would no longer get exceptions on stuff like [42]*42L)). Besides, I'm sure I heard Andrew volunteer to complete all the work by Wednesday <wink>.
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