I just noticed in PEP 3127 (the one that rationalised radix calculations on literals and int()
arguments so that, for example, 010
is no longer a valid literal and must instead be 0o10
if octal is desired), that one particular part of the PEP was not implemented.
I refer specifically to the section quoted below:
Tokenizer exception handling
If an invalid token contains a leading "0", the exception error message should be more informative than the current "SyntaxError: invalid token". It should explain that decimal numbers may not have a leading zero, and that octal numbers require an "o" after the leading zero.
However, when I try to use this (now invalid) format, I still see the old (less informative) error, as per the following transcript:
MyPromptHere> python3
Python 3.6.8 (default, Oct 7 2019, 12:59:55)
[GCC 8.3.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> x = 010
File "<stdin>", line 1
x = 010
^
SyntaxError: invalid token
>>> int('010', 0)
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
ValueError: invalid literal for int() with base 0: '010'
>>> _
Now I don't really care about the fact that it's a weird error since I earn much of my remuneration from arcane errors :-) However, from what I understand, the PEPs go through revision processes even after they've been sponsored so I'm curious as to why either:
Or is this simply the usage of the word "should" having less force than the normal standards "required" terms like "shall" or "must"? I'm not sure of that since, as per the transcript above, "should" appears to be obeyed in the section dealing with int()
:
int()
exception handlingThe
ValueError
raised for any call toint()
with a string should at least explicitly contain the base in the error message, e.g.:ValueError: invalid literal for base 8 int(): 09
.
This might be a python version difference for you.
Python 3.8.1 (default, Jan 13 2020, 22:28:48)
>>> 010
File "<stdin>", line 1
SyntaxError: leading zeros in decimal integer literals are not permitted; use an 0o prefix for octal integers
Also, in the "Open Issues" section of PEP 3127, it states
There are still some strong feelings that '0123' should be allowed as a literal decimal in Python 3.0. If this is the right thing to do, this can easily be covered in an additional PEP. This proposal only takes the first step of making '0123' not be a valid octal number, for reasons covered in the rationale.
To me, this means that there was no hard requirement to change the error message. It was a suggestion to be more informative which was eventually implemented at some point (see 3.8.1 output above).