[Python-3000] Fwd: Re: Fwd: Re: Fwd: Re: Octal

[Guido van Rossum]

On 3/16/07, Patrick Maupin <pmaupin at gmail.com> wrote:
> 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.

I'll take your word that 0X is popular for data files out there. I
think I would support that in int(s, 0) but not in eval(s) -- IOW, hex
literals in Python source code must start with 0x. After that they can
use ABC or abc or AbC for all I care. I used Google's code search to
find occurrences of 0X followed by a hex digit (and not preceded by a
word character) and found only very few hits, many of which were false
positives (e.g. in Python's own test suite there are a bunch of
occurrences in string literals verifying that %#X produces the right
output).

Since this is trivial for the conversion tool, I'm not worried about
breaking that code at all.

-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)