Mark Dickinson dicki...@gmail.com added the comment:
Closing, based on feedback in the comments. Maybe one day...
--
resolution: - later
status: open - closed
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue12127
Mark Dickinson dicki...@gmail.com added the comment:
It does look as though all the arguments were pretty thoroughly hashed out on
the python-3000 list when this was first proposed. See e.g., the thread
starting at:
http://mail.python.org/pipermail/python-3000/2007-March/006262.html
and
Changes by Mark Dickinson dicki...@gmail.com:
--
type: compile error - feature request
versions: +Python 3.3 -Python 3.1, Python 3.2
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue12127
___
Mark Dickinson dicki...@gmail.com added the comment:
I think this is something that should be brought up for wider discussion on the
python-dev mailing list. It may be that people are ready to allow those
leading zeros for Python 3.3 or 3.4.
--
nosy: +mark.dickinson
Changes by Eric V. Smith e...@trueblade.com:
--
nosy: +eric.smith
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue12127
___
___
Python-bugs-list
Ezio Melotti ezio.melo...@gmail.com added the comment:
Do you have any use case for x = 0050?
I don't any reason to adding leading 0s to a literal, but with int() the
situation is different because you might get string with leading 0s from
somewhere else. Also note that the int() function is
Nadeem Vawda nadeem.va...@gmail.com added the comment:
The behaviour of int() can be made consistent with the syntax for Python
integer literals by specifying a base of 0:
int(0050, 0)
Traceback (most recent call last):
File stdin, line 1, in module
ValueError: invalid
Mark Dickinson dicki...@gmail.com added the comment:
Well, I'd personally like to see those leading zeros accepted at some point in
Python's future, for the sake of cleanliness and consistency. Not just
consistency with int(), but also e.g. with float literals:
0050.
50.0
0050
File
Ezio Melotti ezio.melo...@gmail.com added the comment:
If the leading 0s are valid for floats (and complex) literals then int literals
are indeed inconsistent.
If we want consistency with the other literals, it is probably better allowing
them for ints, because removing them from float/complex
Eric V. Smith e...@trueblade.com added the comment:
I don't buy the confusion with other languages argument. It's a different
language. People know that.
I'd like to see leading zeros allowed for integer literals, but I don't feel
strongly about it, so +0. I'd mainly use them for tables of
R. David Murray rdmur...@bitdance.com added the comment:
IMO 3.3 is definitely too soon. 3.4 may be too, depending on how many people
are stuck on legacy systems using 2.7.
--
nosy: +r.david.murray
___
Python tracker rep...@bugs.python.org
Daniel Stutzbach stutzb...@google.com added the comment:
-0 on making it valid ever, due to the different meaning in many other
languages.
-1 on making it valid while many still use a version of python where it's valid
with a different meaning. Maybe for Python 4. ;-)
--
nosy:
New submission from Peter Wentworth p.wentwo...@ict.ru.ac.za:
In Python 3 we no longer have octal literals. The assignment
x = 0050
gives an invalid token error.
But the assignment
y = int(0050) assigns the value 50 to y.
I would advocate consistency in the two situations, and prefer that
Petri Lehtinen pe...@digip.org added the comment:
There's a good rationale against supporting leading zeros in integer literals
in PEP 3127:
http://www.python.org/dev/peps/pep-3127/#removal-of-old-octal-syntax
--
nosy: +petri.lehtinen
versions: +Python 3.2
14 matches
Mail list logo
