[Python-3000] Questions about the Octal literal PEP

[Patrick Maupin]

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