The argument parser seems to have trouble with
sys.maxint on 64-bit platforms:

>>> import sys
>>> sys.maxint
9223372036854775807
>>> sys.setcheckinterval(sys.maxint)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
OverflowError: signed integer is greater than maximum

>>> sys.setcheckinterval(2**31-1)
>>> sys.setcheckinterval(2**31)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
OverflowError: signed integer is greater than maximum

Looks like INT_MAX isn't the right value to test against.

This is on AMD64, Linux2.6, gcc 3.3.

Logged In: YES 
user_id=849994

No, INT_MAX is definitely not the right value. Changed to
LONG_MAX and LONG_MIN in rev. 46741, 46742 (2.4).

Logged In: YES 
user_id=849994

The bug isn't in getargs. Format code "i" wants a C integer.

Question is whether sys.setcheckinterval and perhaps dozens
of other functions should be changed to accept "l".

Changing to Invalid. Reverted checkin.

Logged In: YES 
user_id=38388

Reopened: the bug is still there.

Note that a C integer does have 64-bits on a 64-bit Linux
system :-) (unlike on a Win64 system).

Logged In: YES 
user_id=38388

Strike that last comment about ints haveing 64-bit. I got
carried away by Python using C longs for ints.

Logged In: YES 
user_id=849994

To be sure: ints are 32-bit and longs 64-bit?

Logged In: YES 
user_id=38388

Yes. Sorry for the confusion.

ints are 32 bit and longs 64 bit on 64bit Linux (and other
64bit Unix systems).

Since Python uses C longs for storing integers, sys.maxint
correctly gives LONG_MAX.

Logged In: YES 
user_id=849994

Okay, closing.