Annoying octal notation
ethan at stoneleaf.us
Thu Aug 27 21:22:45 CEST 2009
James Harris wrote:
> On 27 Aug, 18:31, Ethan Furman <et... at stoneleaf.us> wrote:
>>Steven D'Aprano wrote:
>>>A mistake is still a mistake even if it shared with others.
>>>Treating its with a lead zero as octal was a design error when it was
>>>first thought up
>>I have to disagree with you on this one. The computing world was vastly
>>different when that design decision was made. Space was at a premium,
>>programmers were not touch-typists, every character had to count, and
>>why in the world would somebody who had to use papertape or punch cards
>>add a lead zero without a *real* good reason? I submit that that real
>>good reason was to specify an octal literal, and not a decimal literal.
> Nice idea. Characters were expensive but not that expensive - even
> then. One extra character to make the octal prefix 0t or 0q or
> something could have been used. Check out the History heading at
> Note how B migrated away from both BCPL's octal and its hex notation.
> #<octal> and #x<hexadecimal> in BCPL became
> 0<octal> and 0x<hexadecimal> in B
I suspect that as much as anything is was abbreviate as much as
possible. In unix we have copy as cp, list as ls move as mv, etc, etc.
Different mind-set also when designing for yourself or a small group,
versus thousands and thousands.
I am in agreement that Python should not have a leading 0 for octal, as
there are big inconsistencies with how it's treated. Visually, I would
have preferred a prefix of 0c, but I understand it should be consistent
with the string specifier of o. Oh well, win some, lose some.
More information about the Python-list