Home » Python » language lawyer – Are Python PEPs implemented as proposed/amended or is there wiggle room? – Stack Overflow

language lawyer – Are Python PEPs implemented as proposed/amended or is there wiggle room? – Stack Overflow

Posted by: admin February 20, 2020 Leave a comment


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 handling

The ValueError raised for any call to int() 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).