When numbers are 0x80000000 through 0xffffffff and 
020000000000
through 037777777777, it will translate into negative.

Example:

>>> 030000000000
-1073741824
>>> int('030000000000',0)
-1073741824


patches to Python 2.3.4:

Python/compile.c
1259c1259
<               x = (long) PyOS_strtoul(s, &end, 0);
---
>               x = (long) PyOS_strtol(s, &end, 0);

Objects/intobject.c
293c293
<               x = (long) PyOS_strtoul(s, &end, base);
---
>               x = (long) PyOS_strtol(s, &end, base);

Logged In: YES 
user_id=31435

Python is supposed to act this way in 2.3.  It's supposed to 
act the way you want in 2.4.  You didn't say which version of 
Python you're using.  If you used 2.3.4, I'm surprised your 
output didn't contain messages warning that this behavior is 
going to change:

Python 2.3.4 (#53, May 25 2004, 21:17:02) [MSC v.1200 32 
bit (Intel)] on win32
Type "help", "copyright", "credits" or "license" for more 
information.
>>> 030000000000
<stdin>:1: FutureWarning: hex/oct constants > sys.maxint 
will return positive values in Python 2.4 and up
-1073741824
>>> int('030000000000',0)
__main__:1: FutureWarning: int('0...', 0): sign will change in 
Python 2.4
-1073741824
>>>

Which version of Python were you using, and under which OS?

Logged In: YES 
user_id=1057975

I am wondering why should we wait for python 2.4 to fix this 
bug. It just costs two lines changes.

Logged In: YES 
user_id=31435

It's not a bug -- Python has worked this way for more than a 
decade, and changing documented behavior is a slow 
process.  This change is part of those discussed in PEP 237, 
which is in its 3rd year(!) of implementation:

    http://www.python.org/peps/pep-0237.html

Do read the PEP.  Costs here aren't implementation effort, 
they're end-user costs (changes in what Python does require 
users to change their programs, and that's necessarily a 
drawn-out process).

Logged In: YES 
user_id=29957

Closing. This is not going to change in 2.3, but is fixed in
2.4.