[Python-3000] Questions about the Octal literal PEP (original) (raw)

Patrick Maupin pmaupin at gmail.com
Mon Mar 19 20:29:18 CET 2007

On 3/19/07, Raymond Hettinger <raymond at ewtllc.com> wrote:

In Py2.6 and Py3.0, what would these emit:

I do not think we are contemplating breaking anything in 2.6, unless the 3.0 compatibility mode is selected.

map(int, '08:30:00'.split(':')) # handle common decimal string formats with leading zeroes

This will work fine. The way to think of int() is that, if it is passed a string, the default for the optional base parameter is 10. The documentation for int() should make this clearer than it is now.

int('0777', 8) # handle externally created octal literal strings

This will work fine. If the base passed to int() is non-zero, it only expects data characters in the string (no characters to determine the base).

myfile.write(oct(44)) # writing to a file format that requires 054 style output

This one won't work (in 3.0). There are many workarounds. One possibility:

    myfile.write('0%o' % 44)

eval(oct(44)) == 44 # basic invariant for oct(()

Agree this needs to be an invariant -- that's what drives breakage on oct().

If any of those change from Py2.5, it will result in gratuitous code breakage for almost zero benefit.

Should be no breakage on 2.6 in non-3.0 mode, and the one broken feature in 3.0 will be oct(). I did a google search, and there aren't really all that many of those, but it is something I should add to the PEP for the 2to3 tool.

Thanks, Pat

More information about the Python-3000 mailing list