PEP 237 (was RE: Overflow-less integer arithmetic?)

[Tim Peters]

[Andrew Dalke]
> Despite what I said yesterday, I have used and needed lont ints
> a few times in real code.  There are two cases:
>   1) I expect to get large values (>2**31) frequently
>   2) I expect to get them infrequently
>
> Case #1 is the more common, and is solved by using an 'L' in the
> appropriate initialization.  There have been many times when the
> omission of the L was not caught until the testing phase, which
> means automatic conversion would have been prefered.
>
> Case #2 has only occured once, where >98% of the times the
> value could fit in a regular integer and I wanted the
> faster math performance.  In that case I did
>   try:
>     operation
>   except OverflowError:
>     redo the operation with longs

I've used long ints extensively, and indeed I first used Python "for real"
precisely because its long int performance was beating the pants off Icon's
at the time.  Exactly the same two cases apply to me, except that I've done
case #2 hundreds of times.  It's great to hear that I'm not completely out
of tune with your reality <wink>.

> So I have have no problems with the current 237 PEP, where
> int operations convert to long rather than raising an exception.

PEP 237 doesn't mention this, but there's a flip side to your case #2:

def chop(i):
    try:
        return int(i)
    except OverflowError:
        return i

That is, chop back a long to an int "if it fits", again to get the speed
boost in later calculations.  I wonder whether we could get away with that
too ...

one-day-one-revolution-ly y'rs  - tim