[Python-3000] One more question on binary/octal (original) (raw)
Patrick Maupin pmaupin at gmail.com
Thu Mar 15 04🔞43 CET 2007
- Previous message: [Python-3000] Compiling the PEP 3115 metaclass syntax
- Next message: [Python-3000] I18N identifiers
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
As Greg Ewing pointed out (tongue in cheek, I think, but I'm never sure), it would be consistent with 'x' for hexadecimal and 't' for octal to use 'n' for binary rather than 'b', e.g. theanswer = 0n101010
Part of me recoils at this, part of me agrees that this is not any stranger than using 'x' for hex or 't' for octal; and the real reason I am writing this email is that part of me thinks that it would be no fun at all to be staring at a line of Python at 3:00AM wondering why, after executing:
x = 0b0
x doesn't have the value of 176 (0xb0).
Like 'b', 'n' does not appear in the literal words 'hexadecimal' or 'octal', so that is good. 'n' has been chosen to be a "general number" character in PEP3101, but it is not a valid type specifier for the current % operator, so PEP3101 could easily change.
'b' has the advantage of being used in some other languages. OTOH, to a large extent we're eschewing that for internal consistency with Python 3.0, and Greg's 'n' IS more consistent with 'x' and 't' than 'b' is, and if we use 'n' for binary, '0b0' would be quickly caught as an exception, so the disadvantage is momentary.
The primary advantage of 'n' over 'b', of course, is that 'n' is not a valid hexadecimal digit.
So, after I get over my initial shock at thinking about biNary numbers, I have to give Greg's "proposal" a +1.
Regards, Pat
- Previous message: [Python-3000] Compiling the PEP 3115 metaclass syntax
- Next message: [Python-3000] I18N identifiers
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]