On Mon, 14 Mar 2005 14:12:40 -0800, Jeff Shannon <[EMAIL PROTECTED]> wrote:
>John Roth wrote: > >> >> "Charles Hartman" <[EMAIL PROTECTED]> wrote in message >> news:[EMAIL PROTECTED] >> >>>> 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 -- http://mail.python.org/mailman/listinfo/python-list
