[Guido] > ... > In 2.6, I'd be okay with standardizing int on 64 bits everywhere (I > don't think bothering with 128 bits on 64-bit platforms is worth it). > In 2.5, I think we should leave this alone.
Nobody panic. This wasn't on the table for 2.5, and as Martin points out it needs more specification regardless. If the current ~10% slowdown for 32-bit ints in its presence (as measured by something ;-)) persists, I expect it would have a justfiably hard time getting into 2.6. I'm blessing small language changes at the sprint, but so far (and I expect going on) they're harmless. For example, Georg Brandl wanted to change PyErr_NewException() to accept a tuple of base classes, because some of the decimal module's exceptions have multiple bases and coding that bit in C was needlessly convoluted without liberating PyErr_NewException() from its historic single-inheritance limitation. I think that's fine, so approved it. Nevertheless, if someone feels a patch committed to the trunk goes over the edge, do complain to me: it's my job to push back here when needed. OTOH, I expect other "wild ideas" from the sprint to be brought up here, and when they are please just assume that they're not being proposed for 2.5 unless that's explicitly stated. _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
