Mark Dickinson dicki...@gmail.com added the comment:
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
Mark Dickinson dicki...@gmail.com added the comment:
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
Meador Inge mead...@gmail.com added the comment:
Thanks for the analysis Mark. I agree with your points.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15400
___
New submission from Michael Smith kojirom...@gmail.com:
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
Jesús Cea Avión j...@jcea.es added the comment:
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.
--
nosy: +jcea
Meador Inge mead...@gmail.com added the comment:
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
