Implicit would be when some functions would interpret a "0" prefix as octal and others wouldn't.
Regards, Johannes
-- "Meine Gegenklage gegen dich lautet dann auf bewusste Verlogenheit, verl sterung von Gott, Bibel und mir und bewusster Blasphemie." -- Prophet und Vision r Hans Joss aka HJP in de.sci.physik <48d8bf1d$0$7510$54022...@news.sunrise.ch>
On Aug 20, 3:06 pm, David <71da...@libero.it> wrote:
> Hi all,
> Is there some magic to make the 2.x CPython interpreter to ignore the > annoying octal notation?
No. You would have to modify and recompile the interpreter. This is not exactly trivial, see "How to Change Python's Grammar" http://www.python.org/dev/peps/pep-0306/
On Aug 20, 2:06 pm, David <71da...@libero.it> wrote:
> Hi all,
> Is there some magic to make the 2.x CPython interpreter to ignore the > annoying octal notation? > I'd really like 012 to be "12" and not "10".
Use 3.1:
>>> int('012')
12
(Just kidding! That works in 2.5 also. How are you using it where it's coming out wrong? I can see you pulling '012' out of a text file and want to calculate with it, but how would you use a string without using int()? Passing it to functions that allow string representations of numbers?)
On 20 Aug, 20:06, David <71da...@libero.it> wrote:
> Hi all,
> Is there some magic to make the 2.x CPython interpreter to ignore the > annoying octal notation? > I'd really like 012 to be "12" and not "10".
This is (IMHO) a sad hangover from C (which took it from B but not from BCPL which used #<octal> and #x<hex>) and it appears in many places. It sounds like you want to use leading zeroes in literals - perhaps for spacing. I don't think there's an easy way. You just have to be aware of it.
Note that it seems to apply to integers and not floating point literals
>>> 012 10 >>> int("012") 12 >>> 012.5 12.5
This daft notation is recognised in some surprising places to catch the unwary. For example, the place I first came across it was in a windows command prompt:
s:\>ping 192.168.1.012 Pinging 192.168.1.10 with 32 bytes of data:
and note the comment: "An octal constant is the same as a decimal constant except that it begins with a zero. It is then interpreted in base 8. Note that 09 (base 8) is legal and equal to 011."
It maybe made sense once but this relic of the past should have been consigned to the waste bin of history long ago.
Il Thu, 20 Aug 2009 15:18:35 -0700 (PDT), Mensanator ha scritto:
> (Just kidding! That works in 2.5 also. How are you using it where > it's coming out wrong? I can see you pulling '012' out of a text > file and want to calculate with it, but how would you use a > string without using int()? Passing it to functions that allow > string representations of numbers?)
Obviously it's not a progamming issue, just a hassle using the interpreter on command line.
David wrote: > Il Thu, 20 Aug 2009 22:24:24 +0200, Johannes Bauer ha scritto:
>> David schrieb:
>>> If I want an octal I'll use oct()!
>>> "Explicit is better than implicit..." >> A leading "0" *is* explicit.
> It isn't explicit enough, at least IMO.
Is this better?
Python 3.1 (r31:73574, Jun 26 2009, 20:21:35) [MSC v.1500 32 bit (Intel)] on win 32 Type "help", "copyright", "credits" or "license" for more information. >>> 010 File "<stdin>", line 1 010 ^
I would've preferred it to be decimal unless there's a prefix:
Python 3.1 (r31:73574, Jun 26 2009, 20:21:35) [MSC v.1500 32 bit (Intel)] on win 32 Type "help", "copyright", "credits" or "license" for more information. >>> 0x10 16 >>> 0o10 8
On Aug 21, 11:40 am, David <71da...@libero.it> wrote:
> Il Thu, 20 Aug 2009 15:18:35 -0700 (PDT), Mensanator ha scritto:
> > (Just kidding! That works in 2.5 also. How are you using it where > > it's coming out wrong? I can see you pulling '012' out of a text > > file and want to calculate with it, but how would you use a > > string without using int()? Passing it to functions that allow > > string representations of numbers?)
> Obviously it's not a progamming issue, just a hassle using the interpreter > on command line.
Aha! Then I WAS right after all. Switch to 3.1 and you'll soon be cured of that bad habit:
Simon Forman wrote: > On Aug 20, 3:06 pm, David <71da...@libero.it> wrote: >> Hi all,
>> Is there some magic to make the 2.x CPython interpreter to ignore the >> annoying octal notation?
> No. You would have to modify and recompile the interpreter. This is > not exactly trivial, see "How to Change Python's Grammar" > http://www.python.org/dev/peps/pep-0306/
> (Basically in 2.6 and onwards you can use 0oNNN notation.)
Yes, and making lead zeros an error as suggested in PEP 3127 is a good idea. It will be interesting to see what bugs that flushes out.
In 2009, Unisys finally exited the mainframe hardware business, and the last of the 36-bit machines, the ClearPath servers, are being phased out. That line of machines goes back to the UNIVAC 2200 series, and the UNIVAC 1100 series, all the way back to the vacuum-tube UNIVAC 1103 from 1952. It's the longest running series of computers in history, and code for all those machines used octal heavily.
And it's over. We can finally dispense with octal by default.
John Nagle wrote: > Yes, and making lead zeros an error as suggested in PEP 3127 is a > good idea. It will be interesting to see what bugs that flushes > out. James Harris wrote: > It maybe made sense once but this relic of the past should have been > consigned to the waste bin of history long ago.
Sigh. Nonsense. I use octal notation *every day*, for two extremely prevalent purposes: file creation umask, and Unix file permissions (i.e. the chmod() function/command).
I fail to see how 0O012, or even 0o012 is more intelligible than 012. The latter reads like a typo, and the former is virtually indistinguishable from 00012, O0012, or many other combinations that someone might accidentally type (or intentionally type, having to do this in dozens of other programming languages). I can see how 012 can be confusing to new programmers, but at least it's legible, and the great thing about humans is that they can be taught (usually). I for one think this change is completely misguided. More than flushing out bugs, it will *cause* them in ubiquity, requiring likely terabytes of code to be poured over and fixed. Changing decades-old behaviors common throughout a community for the sake of avoiding a minor inconvenience of the n00b is DUMB.
> No. You would have to modify and recompile the interpreter. This is > not exactly trivial, see "How to Change Python's Grammar" > http://www.python.org/dev/peps/pep-0306/
And even that's incorrect. You'd have to modify the tokenizer.
On Fri, Aug 21, 2009 at 08:25:45PM +0000, Benjamin Peterson wrote: > > More than flushing out bugs, it will *cause* them in ubiquity, > > requiring likely terabytes of code to be poured over and fixed.
> 2to3, however, can fix it for you extreme easily.
Sure, but that won't stop people who've been writing code for 20 years from continuing to type octal that way... Humans can learn fairly easily, but UN-learning is often much harder, especially when the behavior to be unlearned is still very commonly in use.
Anyway, whatever. This change (along with a few of the other seemingly arbitrary changes in 3.x) is annoying, but Python is still one of the best languages to code in for any multitude of problems.
>>>>> Derek Martin <c...@pizzashack.org> (DM) wrote: >DM> I fail to see how 0O012, or even 0o012 is more intelligible than 012. >DM> The latter reads like a typo, and the former is virtually >DM> indistinguishable from 00012, O0012, or many other combinations that >DM> someone might accidentally type (or intentionally type, having to do >DM> this in dozens of other programming languages).
You're right. Either hexadecimal should have been 0h or octal should have been 0t :=) -- Piet van Oostrum <p...@cs.uu.nl> URL: http://pietvanoostrum.com [PGP 8DAE142BE17999C4] Private email: p...@vanoostrum.org
Piet van Oostrum wrote: >>>>>> Derek Martin <c...@pizzashack.org> (DM) wrote:
>> DM> I fail to see how 0O012, or even 0o012 is more intelligible than 012. >> DM> The latter reads like a typo, and the former is virtually >> DM> indistinguishable from 00012, O0012, or many other combinations that >> DM> someone might accidentally type (or intentionally type, having to do >> DM> this in dozens of other programming languages).
> You're right. Either hexadecimal should have been 0h or octal should > have been 0t :=)
I have seen the use of Q/q instead in order to make it clearer. I still prefer Smalltalk's 16rFF and 8r377.
On 21 Aug, 20:48, Derek Martin <c...@pizzashack.org> wrote:
...
> James Harris wrote: > > It maybe made sense once but this relic of the past should have been > > consigned to the waste bin of history long ago.
> Sigh. Nonsense. I use octal notation *every day*, for two extremely > prevalent purposes: file creation umask, and Unix file permissions > (i.e. the chmod() function/command).
You misunderstand. I was saying that taking a leading zero as indicating octal is archaic. Octal itself is fine where appropriate.
On 21 Aug, 22:18, MRAB <pyt...@mrabarnett.plus.com> wrote:
> Piet van Oostrum wrote: > >>>>>> Derek Martin <c...@pizzashack.org> (DM) wrote:
> >> DM> I fail to see how 0O012, or even 0o012 is more intelligible than 012. > >> DM> The latter reads like a typo, and the former is virtually > >> DM> indistinguishable from 00012, O0012, or many other combinations that > >> DM> someone might accidentally type (or intentionally type, having to do > >> DM> this in dozens of other programming languages).
> > You're right. Either hexadecimal should have been 0h or octal should > > have been 0t :=)
> I have seen the use of Q/q instead in order to make it clearer. I still > prefer Smalltalk's 16rFF and 8r377.
Two interesting options. In a project I have on I have also considered using 0q as indicating octal. I maybe saw it used once somewhere else but I have no idea where. 0t was a second choice and 0c third choice (the other letters of oct). 0o should NOT be used for obvious reasons.
So you are saying that Smalltalk has <base in decimal>r<number> where r is presumably for radix? That's maybe best of all. It preserves the syntactic requirement of starting a number with a digit and seems to have greatest flexibility. Not sure how good it looks but it's certainly not bad.
0xff & 0x0e | 0b1101 16rff & 16r0e | 2r1101
Hmm. Maybe a symbol would be better than a letter.
Derek Martin <c...@pizzashack.org> writes: > James Harris wrote: > > It maybe made sense once but this relic of the past should have been > > consigned to the waste bin of history long ago.
> Sigh. Nonsense. I use octal notation *every day*, for two extremely > prevalent purposes: file creation umask, and Unix file permissions > (i.e. the chmod() function/command).
Right. Until Unix stops using these (and whatever replaces it would have to be pretty compelling, given the prevalence of these in octal notation), or until people stop using Unix, these will be with us and require octal notation.
That doesn't mean, of course, that we need to elevate it above hexadecimal in our language syntax; 0o012 will allow octal notation for literals just fine.
> I fail to see how 0O012, or even 0o012 is more intelligible than 012. > The latter reads like a typo
No, it reads like a very common notation for decimal numbers in natural usage. It's very frequently not a typo, but an expression of a three-digit decimal number that happens to be less than 100.
> and the former is virtually indistinguishable from 00012, O0012, or > many other combinations that someone might accidentally type (or > intentionally type, having to do this in dozens of other programming > languages).
Only if you type the letter in uppercase. The lower-case o is much easier to distinguish.
Whether or not you find 0o012 easily distinguishable as a non-decimal notation, it's undoubtedly easier to distinguish than 012.
> I can see how 012 can be confusing to new programmers, but at least > it's legible, and the great thing about humans is that they can be > taught (usually). I for one think this change is completely misguided.
These human programmers, whether newbies or long-experienced, also deal with decimal numbers every day, many of which are presented as a sequence of digits with leading zeros and we continue to think of them as decimal numbers regardless. Having the language syntax opposed to that is a wart, a cognitive overhead with little benefit, and I'll be glad to see it go in favour of a clearer syntax.
-- \ one of the main causes of the fall of the Roman Empire was | `\ that, lacking zero, they had no way to indicate successful | _o__) termination of their C programs. Robert Firth | Ben Finney
Derek Martin <c...@pizzashack.org> writes: > Sure, but that won't stop people who've been writing code for 20 years > from continuing to type octal that way... Humans can learn fairly > easily, but UN-learning is often much harder, especially when the > behavior to be unlearned is still very commonly in use.
This is exactly the argument for removing 012 octal notation: humans (and programmers who have far less need for octal numbers than for decimal numbers) are *already* trained, and reinforced many times daily, to think of that notation as a decimal number. They should not need to un-learn that association in order to understand octal literals in code.
> Anyway, whatever. This change (along with a few of the other seemingly > arbitrary changes in 3.x) is annoying, but Python is still one of the > best languages to code in for any multitude of problems.
Hear hear.
-- \ I wrote a song, but I can't read music so I don't know what it | `\ is. Every once in a while I'll be listening to the radio and I | _o__) say, I think I might have written that. Steven Wright | Ben Finney
On Fri, 21 Aug 2009 14:48:57 -0500, Derek Martin wrote: >> It maybe made sense once but this relic of the past should have been >> consigned to the waste bin of history long ago.
> Sigh. Nonsense. I use octal notation *every day*, for two extremely > prevalent purposes: file creation umask, and Unix file permissions (i.e. > the chmod() function/command).
And you will still be able to, by explicitly using octal notation.
> I fail to see how 0O012, or even 0o012 is more intelligible than 012.
The first is wrong, bad, wicked, and if I catch anyone using it, they will be soundly slapped with a halibut. *wink*
Using O instead of o for octal is so unreadable that I think it should be prohibited by the language, no matter that hex notation accepts both x and X.
> The latter reads like a typo,
*Everything* reads like a typo if you're unaware of the syntax being used.
> and the former is virtually > indistinguishable from 00012, O0012, or many other combinations that > someone might accidentally type (or intentionally type, having to do > this in dozens of other programming languages).
Agreed.
> I can see how 012 can > be confusing to new programmers, but at least it's legible, and the > great thing about humans is that they can be taught (usually).
And the great thing is that now you get to teach yourself to stop writing octal numbers implicitly and be write them explicitly with a leading 0o instead :)
It's not just new programmers -- it's any programmer who is unaware of the notation (possibly derived from C) that a leading 0 means "octal". That's a strange and bizarre notation to use, because 012 is a perfectly valid notation for decimal 12, as are 0012, 00012, 000012 and so forth. Anyone who has learnt any mathematics beyond the age of six will almost certainly expect 012 to equal 12. Having 012 equal 10 comes as a surprise even to people who are familiar with octal.
> I for > one think this change is completely misguided. More than flushing out > bugs, it will *cause* them in ubiquity, requiring likely terabytes of > code to be poured over and fixed. Changing decades-old behaviors common > throughout a community for the sake of avoiding a minor inconvenience of > the n00b is DUMB.
Use of octal isn't common. You've given two cases were octal notation is useful, but for every coder who frequently writes umasks on Unix systems, there are a thousand who don't.
1) I am forced to use 2.5 since the production server has 2.5 installed.
2) Quite often I have to enter many zero-leading numbers and now my fingers put a leading zero almost everywhere
3) I don't understand why useless but *harmless* things like algebrically insignificant leading zeros should be *forbidden* and promoted to errors.
4) I still don't like the '0o..' notation because 0 (zero) and o (lowercase O) glyphs appear very similar in many character sets. I'd prefer something like '0c..' so it resembles the word 'oc' for 'octal'.
On Sat, 22 Aug 2009 11:15:16 +0200, David wrote: > 3) I don't understand why useless but *harmless* things like > algebrically insignificant leading zeros should be *forbidden* and > promoted to errors.
The PEP covering this change says:
"There are still some strong feelings that '0123' should be allowed as a literal decimal in Python 3.0. If this is the right thing to do, this can easily be covered in an additional PEP. This proposal only takes the first step of making '0123' not be a valid octal number, for reasons covered in the rationale."
