For my purposes, that would be ideal. But I use Python in unusual ways,
and I wouldn't want to see Python changed if it would slow down everyone
else's programs (just having direct support for unbounded ints in any
guise meets 99% of my weird needs, and I don't at all mind faking the
other percent).
I don't have a good grasp of the pragmatics here. Guido previously
worked on a language that didn't distinguish between "short" and
"unbounded" integers (ABC's basic numeric type is unbounded rational),
and I've just assumed Python's numeric design is a reaction against the
problems he faced before. Unbounded rationals can be a nightmare (as
measured by storage and cycle consumption) for users who don't know what
they're doing, but I'm not sure how much the bounded-vs-unbounded integer
distinction really buys (given an implementation along the lines Doug
suggests, using native C long internally until overflow actually occurs
-- and the short-int routines are already biting the expense of checking
for overflow, so it's "just a matter" of changing how they react to that
rare occurrence). Guido?
There is one semantic difference: as in C, a left shift on a Python short
int silently discards bits (& I think that's a feature), while a left
shift on an unbounded int doesn't lose info. If the distinction is
removed, the latter behavior is the correct one. That would certainly
slow down left shifts, and break some existing programs. Offhand I can't
think of other semantic gotchas ...
if-god-intended-us-to-use-bounded-ints-he-wouldn't-have-given-us-an-
infinite-number-of-fingers-ly y'rs - tim
Tim Peters tim@ksr.com
not speaking for Kendall Square Research Corp