Annoying octal notation

[Ethan Furman]

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
>>
>>[snippage]
>>
>>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
> 
>   http://sundry.wikispaces.com/octal-zero-prefix
> 
> 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
> 
> James

Nice link.

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.

~Ethan~