On Sep 3, 2:57 pm, James Harris wrote:
> On 3 Sep, 14:26, Albert van der Horst
> wrote:
>
> > In article
> > <6031ba08-08c8-416b-91db-ce8ff57ae...@w6g2000yqw.googlegroups.com>,
> > James Harris wrote:
> >
>
> > >So you are saying that Smalltalk has r where
> > >r is presumably for radix? That
Albert van der Horst wrote:
In article <6b5ea596-d1e3-483d-ba79-7b139d3c7...@z24g2000yqb.googlegroups.com>,
Bearophile wrote:
MRAB:
'_': what if in the future we want to allow them in numbers for clarity?
Hettinger says it's hard (= requires too many changes) to do that and
Python programs
On 3 Sep, 15:54, Albert van der Horst
wrote:
> In article ,
> Derek Martin wrote:
>
>
>
>
>
> >--W1uEbMXJ1Mj4g6TI
> >Content-Type: text/plain; charset=iso-8859-1
> >Content-Disposition: inline
>
> >On Mon, Aug 24, 2009 at 05:03:28PM +, Steven D'Aprano wrote:
> >> On Mon, 24 Aug 2009 11:21:46
On 3 Sep, 15:35, Grant Edwards wrote:
...
> >>> Obviously I can't speak for Ken Thompson's motivation in creating this
> >>> feature, but I'm pretty sure it wasn't to save typing or space on
> >>> punchcards. Even in 1969, hex was more common than octal, and yet hex
> >>> values are written with
On 3 Sep, 14:26, Albert van der Horst
wrote:
> In article <6031ba08-08c8-416b-91db-ce8ff57ae...@w6g2000yqw.googlegroups.com>,
> James Harris wrote:
>
>
>
>
> >So you are saying that Smalltalk has r where
> >r is presumably for radix? That's maybe best of all. It preserves the
> >syntactic requi
On 2009-09-03, Albert van der Horst wrote:
> In article ,
> MRAB wrote:
>>Steven D'Aprano wrote:
>
>>> Obviously I can't speak for Ken Thompson's motivation in creating this
>>> feature, but I'm pretty sure it wasn't to save typing or space on
>>> punchcards. Even in 1969, hex was more common th
In article ,
Derek Martin wrote:
>
>--W1uEbMXJ1Mj4g6TI
>Content-Type: text/plain; charset=iso-8859-1
>Content-Disposition: inline
>
>On Mon, Aug 24, 2009 at 05:03:28PM +, Steven D'Aprano wrote:
>> On Mon, 24 Aug 2009 11:21:46 -0500, Derek Martin wrote:
>> > since the old syntax is prevalent b
In article <6b5ea596-d1e3-483d-ba79-7b139d3c7...@z24g2000yqb.googlegroups.com>,
Bearophile wrote:
>MRAB:
>
>>'_': what if in the future we want to allow them in numbers for clarity?
>
>Hettinger says it's hard (= requires too many changes) to do that and
>Python programs don't have big integer co
On Aug 21, 2:45 pm, John Nagle wrote:
> 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 b
In article ,
MRAB wrote:
>Steven D'Aprano wrote:
>> Obviously I can't speak for Ken Thompson's motivation in creating this
>> feature, but I'm pretty sure it wasn't to save typing or space on
>> punchcards. Even in 1969, hex was more common than octal, and yet hex
>> values are written with 0x.
In article <6031ba08-08c8-416b-91db-ce8ff57ae...@w6g2000yqw.googlegroups.com>,
James Harris wrote:
>
>So you are saying that Smalltalk has r 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 gr
On Monday 24 August 2009 16:14:25 Derek Martin wrote:
> In fact, now that I think of it...
>
> I just looked at some old school papers I had tucked away in a family
> album. I'm quite sure that in grammar school, I was tought to use a
> date format of 8/9/79, without leading zeros. I can't prove
On 2009-08-28, Neil Hodgson wrote:
> Steven D'Aprano:
>
>> Obviously I can't speak for Ken Thompson's motivation in creating this
>> feature, but I'm pretty sure it wasn't to save typing or space on
>> punchcards.
>
>The original implementation of UNIX was on a PDP-7 which was an
> 18-bit ma
Steven D'Aprano:
> Obviously I can't speak for Ken Thompson's motivation in creating this
> feature, but I'm pretty sure it wasn't to save typing or space on
> punchcards.
The original implementation of UNIX was on a PDP-7 which was an
18-bit machine. Octal = 3 bits at a a time which evenly
Steven D'Aprano wrote:
On Thu, 27 Aug 2009 10:31:04 -0700, Ethan Furman 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
On Thu, 27 Aug 2009 10:31:04 -0700, Ethan Furman 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
Steven D'Aprano wrote:
> Leading zeroes in decimal numbers are *very* common in dates and times.
In banking too, according to someone at work today.
Mel.
--
http://mail.python.org/mailman/listinfo/python-list
MRAB wrote:
Ethan Furman 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
James Harris wrote:
On 27 Aug, 18:31, Ethan Furman 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. Th
On 27 Aug, 18:31, Ethan Furman 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 computi
Ethan Furman 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
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
On Aug 24, 10:20�pm, Erik Max Francis wrote:
> Steven D'Aprano wrote:
> > On Mon, 24 Aug 2009 09:14:25 -0500, Derek Martin wrote:
>
> >> Assuming I'm right about that, then the use of a leading 0 to represent
> >> octal actually predates the prevalence of using 0 in dates by almost two
> >> decade
Steven D'Aprano wrote:
On Mon, 24 Aug 2009 09:14:25 -0500, Derek Martin wrote:
Assuming I'm right about that, then the use of a leading 0 to represent
octal actually predates the prevalence of using 0 in dates by almost two
decades. And while using leading zeros in other contexts is "familiar"
On Mon, 24 Aug 2009 12:40:24 -0500, Derek Martin wrote:
> On Mon, Aug 24, 2009 at 05:03:28PM +, Steven D'Aprano wrote:
>> On Mon, 24 Aug 2009 11:21:46 -0500, Derek Martin wrote:
>> > since the old syntax is prevalent both within and without the Python
>> > community, making the change is, was,
On Mon, Aug 24, 2009 at 04:40:14PM -0300, Gabriel Genellina wrote:
> En Mon, 24 Aug 2009 14:40:24 -0300, Derek Martin
> escribió:
>
> >Why is it so hard for you to accept that intelligent people can
> >disagree with you, and that what's right for you might be bad for
> >others?
>
> Ask the same
En Mon, 24 Aug 2009 14:40:24 -0300, Derek Martin
escribió:
Why is it so hard for you to accept that intelligent people can
disagree with you, and that what's right for you might be bad for
others?
Ask the same question yourself please.
--
Gabriel Genellina
--
http://mail.python.org/mailma
On Mon, Aug 24, 2009 at 05:03:28PM +, Steven D'Aprano wrote:
> On Mon, 24 Aug 2009 11:21:46 -0500, Derek Martin wrote:
> > since the old syntax is prevalent both within and without the
> > Python community, making the change is, was, and always will be a
> > bad idea.
>
> Octal syntax isn't pre
On Mon, 24 Aug 2009 Derek Martin wrote:
>Those participating in this thread have pretty much all seem to agree
>that the only places where decimal numbers with leading zeros really
>are common are either in rather specialized applications, such as
>computer-oriented data or serial numbers (which ty
On Mon, 24 Aug 2009 11:21:46 -0500, Derek Martin wrote:
> since the old
> syntax is prevalent both within and without the Python community, making
> the change is, was, and always will be a bad idea.
Octal syntax isn't prevalent *at all*, except in a small number of niche
areas.
You've said tha
On Mon, Aug 24, 2009 at 04:47:43PM +, Steven D'Aprano wrote:
> Except of course to anyone familiar with mathematics in the last, oh,
> five hundred years or so. Mathematics has used a positional system for
> numbers for centuries now: leading zeroes have been insignificant, just
> like trail
On Mon, 24 Aug 2009 09:14:25 -0500, Derek Martin wrote:
> Assuming I'm right about that, then the use of a leading 0 to represent
> octal actually predates the prevalence of using 0 in dates by almost two
> decades. And while using leading zeros in other contexts is "familiar"
> to me, I would ce
On Mon, Aug 24, 2009 at 08:31:13AM -0700, Carl Banks wrote:
> On Aug 24, 6:56 am, Derek Martin wrote:
> > I think hard-coding dates is more uncommon than using octal. ;-)
> > [It unquestionably is, for me personally.]
>
> You just don't get it, do you?
I think I get it just fine, thanks.
> Do
On Mon, Aug 24, 2009 at 05:22:39PM +0200, Hendrik van Rooyen wrote:
> > Assuming I'm right about that, then the use of a leading 0 to
> > represent octal actually predates the prevalence of using 0 in dates
> > by almost two decades.
>
> Not quite - at the time I started, punch cards and data ent
On Aug 24, 6:56 am, Derek Martin wrote:
> I think
> hard-coding dates is more uncommon than using octal. ;-) [It
> unquestionably is, for me personally.]
You just don't get it, do you? Do you really think this is a contest
over what's more common and the winner gets to choose the syntax? You
r
On Mon, Aug 24, 2009 at 08:56:48AM -0500, Derek Martin wrote:
> On Sun, Aug 23, 2009 at 01:13:32PM +, Matthew Woodcraft wrote:
> > A more common case is dates.
>
> I suppose this is true, but [...]
> I tend to also discount this example, because when we write dates
> with leading zeros, usuall
On Sun, Aug 23, 2009 at 01:13:32PM +, Matthew Woodcraft wrote:
> Dennis Lee Bieber writes:
> > About the only place one commonly sees leading zeros on decimal
> > numbers, in my experience, is zero-filled COBOL data decks (and since
> > classic COBOL stores in BCD anyway... binary (usage i
On Sun, Aug 23, 2009 at 06:13:31AM +, Steven D'Aprano wrote:
> On Sat, 22 Aug 2009 22:19:01 -0500, Derek Martin wrote:
> > On Sat, Aug 22, 2009 at 02:55:51AM +, Steven D'Aprano wrote:
> >> And the great thing is that now you get to teach yourself to stop
> >> writing octal numbers implicitl
On 21 Aug, 00:59, James Harris wrote:
...
> > 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 ...
This seemed worth writing up so I'
Dennis Lee Bieber writes:
> About the only place one commonly sees leading zeros on decimal
> numbers, in my experience, is zero-filled COBOL data decks (and since
> classic COBOL stores in BCD anyway... binary (usage is
> computational/comp-1) was a later add-on to the data specification mo
MRAB:
>'_': what if in the future we want to allow them in numbers for clarity?
Hettinger says it's hard (= requires too many changes) to do that and
Python programs don't have big integer constants often enough, so
probably that improvement will not see the light.
In the meantime in a Python pr
On Sat, 22 Aug 2009 22:19:01 -0500, Derek Martin wrote:
> On Sat, Aug 22, 2009 at 02:55:51AM +, Steven D'Aprano wrote:
>> > 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).
>>
>>
On Sat, 22 Aug 2009 14:04:17 -0500, Derek Martin wrote:
>> 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 r
On Fri, Aug 21, 2009 at 04:23:57PM -0700, James Harris wrote:
> You misunderstand. I was saying that taking a leading zero as
> indicating octal is archaic. Octal itself is fine where appropriate.
I don't see that the leading zero is any more archaic than the use of
octal itself... Both originate
On Sat, Aug 22, 2009 at 02:55:51AM +, Steven D'Aprano wrote:
> > 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 sto
On Aug 21, 12:48 pm, Derek Martin wrote:
> 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
On Aug 22, 12:04 pm, Derek Martin wrote:
> On Sat, Aug 22, 2009 at 10:03:35AM +1000, Ben Finney wrote:
> > 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
22-08-2009 o 21:04:17 Derek Martin wrote:
On Sat, Aug 22, 2009 at 10:03:35AM +1000, Ben Finney wrote:
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 contin
On Sat, Aug 22, 2009 at 10:03:35AM +1000, Ben Finney wrote:
> > 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
On 2009-08-22, Dennis Lee Bieber wrote:
> On Fri, 21 Aug 2009 10:45:51 -0700, John Nagle
> declaimed the following in gmane.comp.python.general:
>
>>
>> And it's over. We can finally dispense with octal by default.
>>
> I've not looked at modern Intel processor format, but if there a
David wrote:
Il Fri, 21 Aug 2009 16:52:29 -0700 (PDT), James Harris ha scritto:
0xff & 0x0e | 0b1101
16rff & 16r0e | 2r1101
Hmm. Maybe a symbol would be better than a letter.
What about 2_1011, 8_7621, 16_c26h or 2;1011, 8;7621, 16;c26h ?
'_': what if in the future we want to allow th
Dennis Lee Bieber wrote:
On Fri, 21 Aug 2009 16:52:29 -0700 (PDT), James Harris
declaimed the following in
gmane.comp.python.general:
So you are saying that Smalltalk has r where
r is presumably for radix? That's maybe best of all. It preserves the
syntactic requirement of starting a number wi
Il Thu, 20 Aug 2009 16:59:14 -0700 (PDT), James Harris ha scritto:
>
> It maybe made sense once but this relic of the past should have been
> consigned to the waste bin of history long ago.
I perfectly agree with you!
David.
--
http://mail.python.org/mailman/listinfo/python-list
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 b
Il Fri, 21 Aug 2009 16:52:29 -0700 (PDT), James Harris ha scritto:
>
> 0xff & 0x0e | 0b1101
> 16rff & 16r0e | 2r1101
>
> Hmm. Maybe a symbol would be better than a letter.
What about 2_1011, 8_7621, 16_c26h or 2;1011, 8;7621, 16;c26h ?
David
--
http://mail.python.org/mailman/listinfo/pyt
Il Fri, 21 Aug 2009 10:36:35 -0700 (PDT), Mensanator ha scritto:
> Aha! Then I WAS right after all. Switch to 3.1 and you'll
> soon be cured of that bad habit:
>
012 + 012
> SyntaxError: invalid token (, line 1)
I have tre (four) problems:
1) I am forced to use 2.5 since the production ser
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, a
Derek Martin 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
Derek Martin 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
On 21 Aug, 22:18, MRAB wrote:
> Piet van Oostrum wrote:
> >> Derek Martin (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
On 21 Aug, 20:48, Derek Martin 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 creati
Piet van Oostrum wrote:
Derek Martin (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
> Derek Martin (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
On Fri, Aug 21, 2009 at 08:25:45PM +, 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 b
Derek Martin pizzashack.org> writes:
> 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.
--
http://mail.python.org/mailman/listinfo/python-list
Simon Forman gmail.com> writes:
> 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.
--
http://mail.python.o
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 ag
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
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 i
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,
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()? Passin
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.
regards
David
--
http://mail.python.org/mailman/listi
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
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
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://
David schrieb:
> If I want an octal I'll use oct()!
>
> "Explicit is better than implicit..."
A leading "0" *is* explicit.
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 bewus
76 matches
Mail list logo
