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:
- that part of the PEP wasn't implemented; or
- the PEP wasnt revised to reflect reality of the implementation.
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
.