James Harris wrote:
On 27 Aug, 18:31, Ethan Furman <et...@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~
--
http://mail.python.org/mailman/listinfo/python-list
