This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Title: int('12345L', 10) raises ValueError
Type: behavior Stage: needs patch
Components: Interpreter Core Versions: Python 2.7
Status: closed Resolution: wont fix
Dependencies: Superseder:
Assigned To: Nosy List: Michael.Smith, jcea, mark.dickinson, meador.inge
Priority: normal Keywords:

Created on 2012-07-19 19:21 by Michael.Smith, last changed 2022-04-11 14:57 by admin. This issue is now closed.

Messages (6)
msg165862 - (view) Author: Michael Smith (Michael.Smith) Date: 2012-07-19 19:21
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
msg165870 - (view) Author: Jesús Cea Avión (jcea) * (Python committer) Date: 2012-07-19 19:40
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.
msg165895 - (view) Author: Meador Inge (meador.inge) * (Python committer) Date: 2012-07-20 02:15
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
>>> sys.maxint + 1
>>> int(sys.maxint)
>>> int(sys.maxint + 1)
>>> int(9223372036854775807)
>>> int('9223372036854775807')
>>> int(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')
>>> int(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?
msg165908 - (view) Author: Mark Dickinson (mark.dickinson) * (Python committer) Date: 2012-07-20 10:24
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.
msg165909 - (view) Author: Mark Dickinson (mark.dickinson) * (Python committer) Date: 2012-07-20 10:34
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/ for it :-(
msg165925 - (view) Author: Meador Inge (meador.inge) * (Python committer) Date: 2012-07-20 13:55
Thanks for the analysis Mark.  I agree with your points.
Date User Action Args
2022-04-11 14:57:33adminsetgithub: 59605
2012-07-20 13:55:40meador.ingesetmessages: + msg165925
2012-07-20 10:34:45mark.dickinsonsetstatus: open -> closed
resolution: wont fix
messages: + msg165909
2012-07-20 10:24:45mark.dickinsonsetnosy: + mark.dickinson
messages: + msg165908
2012-07-20 02:15:13meador.ingesetstatus: closed -> open

nosy: + meador.inge
messages: + msg165895

resolution: wont fix -> (no value)
stage: resolved -> needs patch
2012-07-19 19:40:49jceasetstatus: open -> closed

nosy: + jcea
messages: + msg165870

resolution: wont fix
stage: resolved
2012-07-19 19:21:43Michael.Smithcreate