[Python-3000] Fwd: Re: Fwd: Re: Fwd: Re: Octal
Patrick Maupin
pmaupin at gmail.com
Sat Mar 17 05:40:24 CET 2007
On 3/16/07, Guido van Rossum <guido at python.org> wrote:
> Cool. Then I'll support your support for 0o, and only using lowercase
> 0b, 0o, 0x. Maybe that'll settle the discussion about this bikeshed's
> color. I'm also in favor of only using lowercase j for complex and
> lowercase r for raw strings. (u will disappear with the Unicode/str
> unification.)
In general, I support this, and weary of discussing and documenting
the exact shade of battleship grey we have decided upon.
However, I need to ask about one blue racing stripe along the left-hand side :)
Hexadecimal numbers traditionally support upper- and lower-case
display, chosen by the case of the 'x' character. Python supports
this both for input and display, and probably needs to continue to
support the option of upper or lowercase hex for display.
I think perhaps it should be supported for input, as well, both to
have symmetry with the display, and to allow for easy cut and paste
(and eval() and int(s, 0)) of hexadecimal numbers from other sources.
Obviously, we cannot support this easy eval() or int(s, 0) for octal
in the future, but arguably, there are a lot more hexadecimal numbers
of either case "in the wild" than there are octal numbers.
I understand that the proposal is to allow 0xabc or 0xABC, but not
allow 0Xabc or 0XABC, but one of the strengths of Python is that I can
easily parse files containing numerical data from almost arbitrary
sources, and this may be a case where "practicality beats purity"
should rule, although it may also be an easy counterargument that I/O
symmetry is not really that important, and that one can easily write
"x = x.replace('0X', '0x')" for the example I have given. Your call.
Regards,
Pat
More information about the Python-3000
mailing list