[Python-Dev] Octal literals

[Josiah Carlson]

bokr at oz.net (Bengt Richter) wrote:
> On Wed, 01 Feb 2006 09:47:34 -0800, Josiah Carlson <jcarlson at uci.edu> wrote:
> >bokr at oz.net (Bengt Richter) wrote:
> >> On Wed, 01 Feb 2006 12:33:36 +0000, "Gustavo J. A. M. Carneiro" <gjc at inescporto.pt> wrote:
> >> [...]
> >> >  Hmm.. I'm beginning to think 13r16 or 16r13 look too cryptic to the
> >> >casual observer; perhaps a suffix letter is more readable, since we
> >> >don't need arbitrary radix support anyway.
> >
> >[snip discussion over radix and compliments]
> >
> >I hope I'm not the only one who thinks that "simple is better than
> >complex", at least when it comes to numeric constants.  Certainly it
> >would be _convenient_ to express constants in a radix other than decimal,
> >hexidecimal, or octal, but to me, it all looks like noise.
> 
> You don't have to use any other radix, any more than you have to use all forms
> of float literals if you are happy with xx.yy. The others just become available
> through a consistent methodology.
> 
> >Peronally, I was on board for the removal of octal literals, if only
> >because I find _seeing_ a leading zero without something else (like the
> >'x' for hexidecimal) to be difficult, and because I've found little use
> >for them in my work (decimals and hex are usually all I need).
> 
> I agree that 8r641 is more easily disambiguated than 0641 ;-)
> 
> But how do you represent a negative int in hex? Or have you never encountered the need?
> The failure of current formats with respect to negative values whose values you
> want to specify in a bit-specifying format was my main point.

In my experience, I've rarely had the opportunity (or misfortune?) to
deal with negative constants, whose exact bit representation I needed to
get "just right".  For my uses, I find that specifying "-0x..." or "-..."
to be sufficient.

Certainly it may or may not be the case in what you are doing (hence
your exposition on signs, radixes, etc.).

Would the i32() function you previously defined, as well as a utility
h32() function which does the reverse be a reasonable start?  Are there
any radixes beyond binary, octal, decimal, and hexidecimal that people
want to use?  Does it make sense to create YYrXXXXX syntax for integer
literals for basically 4 representations, all of which can be handled by
int('XXXXXX', YY) (ignoring the runtime overhead)?  Does the suffix idea
for different types (long, decimal, ...) necessarily suggest that
suffixes for radixes for one type (int/long) is a good idea (1011b,
2000o, ...) are a good idea?

I'll expand what I said before; there are many things that would make
integer literals more convenient for heavy (or experienced) users of
non-decimal or non-decimal-non-positive literals, but it wouldn't
necessarily increase the understandability of code which uses them.

 - Josiah