[Python-Dev] Octal literals (original) (raw)

Josiah Carlson jcarlson at uci.edu
Wed Feb 1 20:07:17 CET 2006

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.

More information about the Python-Dev mailing list