[Python-Dev] Changing python int to "long long".

[Tim Peters]

[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.