The trailing 'L' in representations of long integers causes the int function to raise a ValueError. This is unexpected because it's reasonable to expect that `int` should be able to parse a number from any string when that string represented as a bare word would be a valid python number. The following all raise ValueError:

int(hex(12345L), 16)
int(oct(12345L), 8)

but not

int('12345', 10)
int(hex(12345), 16)
int(oct(12345), 8)
(and not bin() because of http://bugs.python.org/issue3186)

This problem is real but 2.7 is open only for bugfixes (no enhancements) and 3.x doesn't generate the "l" suffix anymore.

I am closing this issue as "won't fix". If you think this is a mistake, please reopen and argument it.

It could be argued that this is a bug fix for 2.7.  I find the current behavior odd at best since 'int' already accepts 'long' objects, but not the string representation of a 'long' object:

>>> sys.maxint
9223372036854775807
>>> sys.maxint + 1
9223372036854775808L
>>> int(sys.maxint)
9223372036854775807
>>> int(sys.maxint + 1)
9223372036854775808L
>>> int(9223372036854775807)
9223372036854775807
>>> int('9223372036854775807')
9223372036854775807
>>> int(9223372036854775808L)
9223372036854775808L
>>> int('9223372036854775808L')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ValueError: invalid literal for int() with base 10: '9223372036854775808L'
>>> long('9223372036854775808L')
9223372036854775808L
>>> int(1)
1
>>> int('1L')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ValueError: invalid literal for int() with base 10: '1L'

Let's discuss this a bit before closing it.  What do others think?

I definitely think this counts as a feature request, and as such should be rejected.

I'd expect the 'long' constructor to be able to parse representations of both ints and longs, but I don't see any reason to expect the 'int' constructor to be able to parse representations of longs.

Reclosing this:  it's at worst marginally a bug, and not worth the new code that would have to go into 2.7.

@Meador:  consider also that int accepts float objects, but not string representations of float objects...  I don't see any real reason for concern here.

I'm certain this is intentional behaviour, but a little bit disappointed that I couldn't find a test already in Lib/test/test_int.py for it :-(

Thanks for the analysis Mark.  I agree with your points.