Python-list Digest, Vol 18, Issue 208

[Bengt Richter]

On Mon, 14 Mar 2005 14:12:40 -0800, Jeff Shannon <jeffshannon at gmail.com> wrote:

>John Roth wrote:
>
>> 
>> "Charles Hartman" <charles.hartman at conncoll.edu> wrote in message 
>> news:mailman.370.1110772426.1799.python-list at python.org...
>> 
>>>> I know this isnt that big of a problem,
>>>> but i cannot think of one reason why they would not allow numbers 
>>>> preceded with a 0 to have a number
>>>> higher then a 7 in them...
>>>> And it seems very inconsistant to me...
>>>
>>> I *love* questions I can answer! Answer: because that's how you tell 
>>> Python you're entering an octal number. 
>> 
>> That's a reason, but I don't consider it a good reason.
>> I cannot, in fact, think of a single time when I've wanted
>> to enter an octal number. Hex numbers, yes, but  not
>> octal.
>> 
>> I personally don't think the frequency of use warrents
>> the special case syntax and the resultant confusion
>> with novices.
>
>I would agree with you, but it's there for historical reasons.  This 
>is a pretty common convention that Python (I believe) borrowed from C. 
>  Octal *used* to be useful, when there were machines with word sizes 
>in multiples of 3 (e.g. 18- and 27-bit words), since one octal digit 
>exactly represents 3 bits (just as one hex digit exactly represents 4 
>bits); now that almost the entire industry has standardized on 
>power-of-2 word sizes, octal is nearly useless but is still carried 
>about for backwards compatibility.
>
Actually, octal was really handy for PDP-11/45 core dumps, even though
it had a power-of-2 (4 -> 16 bits) word size. The reason was that
the addressing modes for instructions were specified in 3-bit fields
which happened to line up nicely into single octal characters,
and the rest easily identified the instructions.

Reading-octal-was-just-reading-a-dialect-of-assembler-ly

Regards,
Bengt Richter