Re: Numeric literal syntax
On Tue, 09 Sep 2008 08:32:29 +1000, Tom Harris wrote: > I agree. So did Forth's early designers. That is why Forth's number > parser considers a word that starts with a number and has embedded > punctuation to be a 32 bit integer, and simply ignores the punctuation. > I haven't used Forth in years, but it seems a neat solution to the > problem of decoding a long string of numbers: let the user put in > whatever they want, the parser ignores it. I usually used a comma (with > no surrounding whitespace of course), but it was your choice. You could > also do this in whatever base you were working in, so you could > punctuate a 32 bit hex number to correspond to the bit fields inside it. > Of course not applicable to Python. That sounds like a great idea, except I'd specify non-period (.) punctuation, so it would go for floating points as well. Is there a language design guru who can say why inputs like 123,456.00 couldn't be handles as above? the only problem I can see is an abiguity in argument lists (e.g. mult(2,4) ) which could be handled by the inclusion of whitespace. -- http://mail.python.org/mailman/listinfo/python-list
Re: Numeric literal syntax
On Thu, Sep 4, 2008 at 10:22 AM, Alexander Schmolck <[EMAIL PROTECTED]> wrote: > > It's amazing that after over half a century of computing we still can't denote > numbers with more than 4 digits readably in the vast majority of contexts. > I agree. So did Forth's early designers. That is why Forth's number parser considers a word that starts with a number and has embedded punctuation to be a 32 bit integer, and simply ignores the punctuation. I haven't used Forth in years, but it seems a neat solution to the problem of decoding a long string of numbers: let the user put in whatever they want, the parser ignores it. I usually used a comma (with no surrounding whitespace of course), but it was your choice. You could also do this in whatever base you were working in, so you could punctuate a 32 bit hex number to correspond to the bit fields inside it. Of course not applicable to Python. -- Tom Harris -- http://mail.python.org/mailman/listinfo/python-list
Re: Numeric literal syntax
On Sat, 06 Sep 2008 23:30:03 +, Alan G Isaac wrote: >> [EMAIL PROTECTED] writes: >> >>> For Python 2.7/3.1 I'd now like to write a PEP regarding the >>> underscores into the number literals, like: 0b_0101_, 268_435_456 >>> etc. >> >> +1 on such a capability. >> >> -1 on underscore as the separator. > > > On 9/1/2008 9:13 PM Ben Finney apparently wrote: >> When you proposed this last year, the counter-proposal was made >> http://groups.google.com/group/comp.lang.python/ msg/18123d100bba63b8?dmode=source> >> to instead use white space for the separator, exactly as one can now do >> with string literals. > > Yuck. > Repeating a mistake means two mistakes. A lot of us don't think that white space between string literals was a mistake. A lot of us consider it a desirable feature. > But I would hate less the use of nobreak spaces, since any decent editor > can reveal them. How do you type a nobreak space? It's also probably a bad idea for Python the language to depend on developers using "a decent editor", since many people disagree on what a decent editor is, and many other people don't have access to whatever you consider "a decent editor". -- Steven -- http://mail.python.org/mailman/listinfo/python-list
Re: Numeric literal syntax
[EMAIL PROTECTED] writes: For Python 2.7/3.1 I'd now like to write a PEP regarding the underscores into the number literals, like: 0b_0101_, 268_435_456 etc. +1 on such a capability. -1 on underscore as the separator. On 9/1/2008 9:13 PM Ben Finney apparently wrote: When you proposed this last year, the counter-proposal was made http://groups.google.com/group/comp.lang.python/msg/18123d100bba63b8?dmode=source> to instead use white space for the separator, exactly as one can now do with string literals. Yuck. Repeating a mistake means two mistakes. But I would hate less the use of nobreak spaces, since any decent editor can reveal them. Alan Isaac -- http://mail.python.org/mailman/listinfo/python-list
Re: Numeric literal syntax
Alexander Schmolck wrote: A problem is that '1234' in Python is a string, so using ' in numbers looks a bit dangerous to me (and my editor will color those numbers as alternated strings, I think). Yeah, editors, especially those with crummy syntax highlighting (like emacs) might get it wrong. This should be easy enough to fix though. instead of forcing all editor developers to change their Python modes to allow you to use a crude emulation of a typographic convention in your Python source code, why not ask a few of them to implement the correct typographic convention (thin spaces) in their Python mode? -- http://mail.python.org/mailman/listinfo/python-list
Re: Numeric literal syntax
[EMAIL PROTECTED] writes: > A problem is that '1234' in Python is a string, so using ' in numbers > looks a bit dangerous to me (and my editor will color those numbers as > alternated strings, I think). Yeah, editors, especially those with crummy syntax highlighting (like emacs) might get it wrong. This should be easy enough to fix though. Indeed unlike raw and tripplequoted strings which were adopted without major hitches this new syntax wouldn't have any bearing on what's a valid string. 'as -- http://mail.python.org/mailman/listinfo/python-list
Re: Numeric literal syntax
Steven D'Aprano <[EMAIL PROTECTED]> writes: > On Thu, 04 Sep 2008 01:22:22 +0100, Alexander Schmolck wrote: > >> It seems to me that the right choice for thousands seperator is the >> apostrophe. > > You mean the character already used as a string delimiter? Yup. No ambiguity or problem here; indeed unlike space seperation or '_' it would work straighforwardly as a syntax extension in pretty much any programming language I can think as well as end-user output (I think that writing e.g. 1'000'000 on a website would be perfectly acceptable; unlike 1_000_000). 'as -- http://mail.python.org/mailman/listinfo/python-list
RE: Numeric literal syntax
Steven D'Aprano wrote: > On Thu, 04 Sep 2008 01:22:22 +0100, Alexander Schmolck wrote: > >> It seems to me that the right choice for thousands seperator is the >> apostrophe. > > You mean the character already used as a string delimiter? Hey - I just found a new use for the backtick! 123`456`7890 0b`1001`0110 Note: Guido has stated that the backtick will *not* be given a new meaning in any future version of Python ... Tim Delaney -- http://mail.python.org/mailman/listinfo/python-list
Re: Numeric literal syntax
On Thu, 04 Sep 2008 01:22:22 +0100, Alexander Schmolck wrote: > It seems to me that the right choice for thousands seperator is the > apostrophe. You mean the character already used as a string delimiter? -- Steven -- http://mail.python.org/mailman/listinfo/python-list
Re: Numeric literal syntax
Alexander Schmolck: > It also reads well, unlike the underscore > which is visually obstrusive and ugly (compare 123'456'890 to 123_456_789). I like that enough, in my language that symbol is indeed the standard one to separate thousands, in large numbers. It's light, looks natural, and as you say it's visually unobstrusive. But in my language ' means just thousands, so it's used only in blocks of 3 digits, not in blocks of any length, so something like this looks a bit strange/wrong: 0b'' While the underscore has no meaning, so it can be used in both situations. A problem is that '1234' in Python is a string, so using ' in numbers looks a bit dangerous to me (and my editor will color those numbers as alternated strings, I think). Note that for other people the ' denotes feet, while in my language it denotes minutes, while I think the underscore has no meaning. So for me the underscore is better :-) Bye, bearophile -- http://mail.python.org/mailman/listinfo/python-list
Re: Numeric literal syntax
Ben Finney <[EMAIL PROTECTED]> writes: > [EMAIL PROTECTED] writes: > >> For Python 2.7/3.1 I'd now like to write a PEP regarding the >> underscores into the number literals, like: 0b_0101_, 268_435_456 >> etc. > > +1 on such a capability. > > -1 on underscore as the separator. > > When you proposed this last year, the counter-proposal was made > http://groups.google.com/group/comp.lang.python/msg/18123d100bba63b8?dmode=source> > to instead use white space for the separator, exactly as one can now > do with string literals. > > I don't see any good reason (other than your familiarity with the D > language) to use underscores for this purpose, and much more reason > (readability, consistency, fewer arbitrary differences in syntax, > perhaps simpler implementation) to use whitespace just as with string > literals. It seems to me that the right choice for thousands seperator is the apostrophe. It doesn't suffer from brittleness and editing problems as whitespace does (e.g. consider filling and auto-line breaking). It is already used in some locales for this function but never for the decimal point (so no ambiguity, unlike '.' and ','). It also reads well, unlike the underscore which is visually obstrusive and ugly (compare 123'456'890 to 123_456_789). Having said that, I'd still have 123_456_789 over 123456789 any day. It's amazing that after over half a century of computing we still can't denote numbers with more than 4 digits readably in the vast majority of contexts. 'as -- http://mail.python.org/mailman/listinfo/python-list
Re: Numeric literal syntax
On Sep 2, 12:34 am, Fredrik Lundh <[EMAIL PROTECTED]> wrote: > Ben Finney wrote: > > I would argue that the precedent, already within Python, for using a > > space to separate pieces of a string literal, is more important than > > precedents from other programming languages. > > that precedent also tells us that the whitespace approach is a common > source of errors. taking an approach that's known to be error-prone and > applying it to more cases isn't necessarily a great way to build a > better language. > > Also a source of mental complexity. The two proposals (whitespace vs. underscores) are not just a question of what character to use, it's a question of whether to create an integer (and possibly other numeric type) literal that allows delimiters, or to allow separate literals to be concatenated. In the second case, which of the following would be proper syntax? 0b1001 0110 0b1001 0b0110 In the first case, the second literal, on its own, is an octal literal, but we expect it to behave as a binary literal. In the second case, we have more consistency with string literals (with which you can do this: "abc" r'''\def''') but we lose the clarity of using the concatenation to make the whole number more readable. On the other hand, 0b1001_0110 has one clear meaning. It is one literal that stands alone. I'm not super thrilled about the look (or keyboard location) of the underscore, but it's better than anything else that is available, and works within a single numeric literal. For this reason I am +0 on the underscore and -1 on the space. -- http://mail.python.org/mailman/listinfo/python-list
Re: Numeric literal syntax
Ben Finney: > … for numbers with many digits the digits may be divided into > groups of three by a thin space, in order to facilitate reading. > Neither dots nor commas are inserted in the spaces between groups > of three. > http://www.bipm.org/en/si/si_brochure/chapter5/5-3-2.html#5-3-4> > This isn't binding upon Python, of course. However, it should be a > consideration in choosing what separator convention to follow. It confirms what I say :-) A thin space doesn't break the gestalt of the number, while a normal space, especially if you use a not proportional font with good readability (and characters well spaced) breaks the single gestalt of the number. Bye, bearophile -- http://mail.python.org/mailman/listinfo/python-list
Re: Numeric literal syntax
On 2008-09-03, Ben Finney <[EMAIL PROTECTED]> wrote: > Another reason in support of spaces (rather than underscores) to > separate digit groups: it's the only separator that follows the SI > standard for representing numbers: > > ??? for numbers with many digits the digits may be divided into > groups of three by a thin space, in order to facilitate reading. > Neither dots nor commas are inserted in the spaces between groups > of three. > > http://www.bipm.org/en/si/si_brochure/chapter5/5-3-2.html#5-3-4> > > This isn't binding upon Python, of course. However, it should > be a consideration in choosing what separator convention to > follow. I don't think that standard is applicable. It's a typesetting style guide. It also references superscripts, half-high centered dots, the "cross" multiplication symbol, the degree symbol and tons of other things which, like the thin space, can't be represented using the most common text encodings. It's quite explicit that the separator is a thin space, which one presumes would not be considered "white space" for tokenizing purposes. We don't have a thin-space, and allowing spaces within numerical literals would throw a major monkey-wrench into a lot of things (like data files whose values are separated by a single space). I suppose you could have a different format for literals in program source and for the operands to int() and float(), but that feels like a bad idea. -- Grant Edwards grante Yow! Pardon me, but do you at know what it means to be visi.comTRULY ONE with your BOOTH! -- http://mail.python.org/mailman/listinfo/python-list
Re: Numeric literal syntax
On 2008-09-03, Ben Finney <[EMAIL PROTECTED]> wrote: > Ben Finney <[EMAIL PROTECTED]> writes: > >> I don't see any good reason (other than your familiarity with the D >> language) to use underscores for this purpose, and much more reason >> (readability, consistency, fewer arbitrary differences in syntax, >> perhaps simpler implementation) to use whitespace just as with string >> literals. > > Another reason in support of spaces (rather than underscores) to > separate digit groups: it's the only separator that follows the SI > standard for representing numbers: > > ??? for numbers with many digits the digits may be divided into > groups of three by a thin space, in order to facilitate reading. > Neither dots nor commas are inserted in the spaces between groups > of three. But my keyboard doesn't _have_ a thin-space key! -- Grant Edwards grante Yow! One FISHWICH coming at up!! visi.com -- http://mail.python.org/mailman/listinfo/python-list
Re: Numeric literal syntax
On 2008-09-02, Christian Heimes <[EMAIL PROTECTED]> wrote: > Fredrik Lundh wrote: >> Peter Pearson wrote: >> >>> (startled noises) It is a delight to find a reference to >>> that half-century-old essay (High Finance) by the wonderful >>> C. Northcote Parkinson, but how many readers will catch the >>> allusion? >> >> anyone that's been involved in open source on the development side for >> more than, say, ten minutes. > > Indeed! Thus speaks the experienced developer -- effbot :) > > On some mailing lists the bikeshed issue comes hand in hand with the > Dunning-Kruger-effect. [1] *sigh* > > Christian > > [1] http://en.wikipedia.org/wiki/Dunning-Kruger_effect That paper is really very interesting -- it explains a lot of what one sees in corporate life. -- Grant Edwards grante Yow! I just remembered at something about a TOAD! visi.com -- http://mail.python.org/mailman/listinfo/python-list
Re: Numeric literal syntax
Ben Finney <[EMAIL PROTECTED]> writes: > I don't see any good reason (other than your familiarity with the D > language) to use underscores for this purpose, and much more reason > (readability, consistency, fewer arbitrary differences in syntax, > perhaps simpler implementation) to use whitespace just as with string > literals. Another reason in support of spaces (rather than underscores) to separate digit groups: it's the only separator that follows the SI standard for representing numbers: … for numbers with many digits the digits may be divided into groups of three by a thin space, in order to facilitate reading. Neither dots nor commas are inserted in the spaces between groups of three. http://www.bipm.org/en/si/si_brochure/chapter5/5-3-2.html#5-3-4> This isn't binding upon Python, of course. However, it should be a consideration in choosing what separator convention to follow. -- \ “If you ever catch on fire, try to avoid seeing yourself in the | `\mirror, because I bet that's what REALLY throws you into a | _o__) panic.” —Jack Handey | Ben Finney -- http://mail.python.org/mailman/listinfo/python-list
Re: Numeric literal syntax (was: Py 2.6 changes)
On Sep 2, 6:35 am, Nick Craig-Wood <[EMAIL PROTECTED]> wrote: > [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > > It's not just my familiarity, Ada language too uses underscore for > > that purpose, I think, so there's a precedent, and Ada is a language > > designed to always minimize programming errors, simple code mistakes > > too. > > And perl also Add Verilog to that list. The ability to embed underscores in numeric literals, which the parser discards, is sometimes very useful in hardware description, especially when dealing with binary bit vectors which can sometimes be 32 bits or more long. Underscores are great. I have actually wished for this in Python myself, for those cases when I am doing binary. Spaces, not so much -- as others have pointed out, this is error prone, partly because spaces are "light weight" visually, and partly because the parser does not currently distinguish between different kinds of whitespace. I can't count how often I've forgotten a trailing comma on a line of items. To the complaints about the underscores getting in the way -- if the number is short, you don't need either underscores or spaces, and if the number is long, it's much easier to count underscores to find your position than it is to count spaces. Also, on long numbers (where this is most useful), the issue with mistaking a number for an identifier is much less likely to happen in real life. I think the issue of location sensitivity has already been flogged enough, but I will give it one last hit -- long numbers, where this is most useful, are often encountered in domain-specific mini languages, where the number of digits in each portion of a number might have some specific meaning. If the proposal were restricted to "once every 3 digits" or something similar, it would not be worth doing at all. +1 on the original proposal. Pat -- http://mail.python.org/mailman/listinfo/python-list
Re: Numeric literal syntax
Peter Pearson <[EMAIL PROTECTED]> writes: > I thought I was a geek, for the past 40 years; but maybe its time > for me to be demoted to the dad on whose bookshelf you'll find that > old book. Once a geek, always a geek. You either stay sharp or get sloppy, but you never stop being a geek :-) -- \ “The best ad-libs are rehearsed.” —Graham Kennedy | `\ | _o__) | Ben Finney -- http://mail.python.org/mailman/listinfo/python-list
Re: Numeric literal syntax
Fredrik Lundh wrote: Peter Pearson wrote: (startled noises) It is a delight to find a reference to that half-century-old essay (High Finance) by the wonderful C. Northcote Parkinson, but how many readers will catch the allusion? anyone that's been involved in open source on the development side for more than, say, ten minutes. Indeed! Thus speaks the experienced developer -- effbot :) On some mailing lists the bikeshed issue comes hand in hand with the Dunning-Kruger-effect. [1] *sigh* Christian [1] http://en.wikipedia.org/wiki/Dunning-Kruger_effect -- http://mail.python.org/mailman/listinfo/python-list
Re: Numeric literal syntax
On Tue, 02 Sep 2008 17:18:58 GMT, Alan G Isaac <[EMAIL PROTECTED]> wrote: >> On 02 Sep 2008 06:10:51 GMT, Steven D'Aprano wrote: >>> At the risk of bike-shedding, >> [snip] > > Peter Pearson wrote: >> (startled noises) It is a delight to find a reference to >> that half-century-old essay (High Finance) by the wonderful >> C. Northcote Parkinson, but how many readers will catch the >> allusion? > > It is pretty common geek speek: > http://en.wikipedia.org/wiki/Color_of_the_bikeshed Ah, the wondrous Wiki. I thought I was a geek, for the past 40 years; but maybe its time for me to be demoted to the dad on whose bookshelf you'll find that old book. -- To email me, substitute nowhere->spamcop, invalid->net. -- http://mail.python.org/mailman/listinfo/python-list
Re: Numeric literal syntax
Peter Pearson wrote: (startled noises) It is a delight to find a reference to that half-century-old essay (High Finance) by the wonderful C. Northcote Parkinson, but how many readers will catch the allusion? anyone that's been involved in open source on the development side for more than, say, ten minutes. http://www.bikeshed.com/ -- http://mail.python.org/mailman/listinfo/python-list
Re: Numeric literal syntax
On 02 Sep 2008 06:10:51 GMT, Steven D'Aprano wrote: At the risk of bike-shedding, [snip] Peter Pearson wrote: (startled noises) It is a delight to find a reference to that half-century-old essay (High Finance) by the wonderful C. Northcote Parkinson, but how many readers will catch the allusion? It is pretty common geek speek: http://en.wikipedia.org/wiki/Color_of_the_bikeshed Cheers, Alan Isaac -- http://mail.python.org/mailman/listinfo/python-list
Re: Numeric literal syntax (was: Py 2.6 changes)
On 02 Sep 2008 06:10:51 GMT, Steven D'Aprano wrote: > At the risk of bike-shedding, [snip] (startled noises) It is a delight to find a reference to that half-century-old essay (High Finance) by the wonderful C. Northcote Parkinson, but how many readers will catch the allusion? -- To email me, substitute nowhere->spamcop, invalid->net. -- http://mail.python.org/mailman/listinfo/python-list
Re: Numeric literal syntax (was: Py 2.6 changes)
[EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > Ben Finney: > > I don't see any good reason (other than your familiarity with the D > > language) to use underscores for this purpose, and much more reason > > (readability, consistency, fewer arbitrary differences in syntax, > > perhaps simpler implementation) to use whitespace just as with string > > literals. > > It's not just my familiarity, Ada language too uses underscore for > that purpose, I think, so there's a precedent, and Ada is a language > designed to always minimize programming errors, simple code mistakes > too. And perl also *ducks* -- Nick Craig-Wood <[EMAIL PROTECTED]> -- http://www.craig-wood.com/nick -- http://mail.python.org/mailman/listinfo/python-list
Re: Numeric literal syntax
On Mon, 01 Sep 2008 22:11:13 -0700, Dennis Lee Bieber wrote: > On Tue, 02 Sep 2008 13:51:16 +1000, Ben Finney > <[EMAIL PROTECTED]> declaimed the following in > comp.lang.python: > >> This is no more the case than for literal strings: >> >> a = "spam" "eggs" "ham" >> >> a = "spam", "eggs", "ham" >> > But... Literal string still have the " (or ') delimiters around the > components. Such does not exist for you example with integers. > > Consider > > a = "spam, eggs", "ham" > vs > a = "spam, eggs" "ham" Quite frankly, I think that it's a stretch to say that leaving out a tuple delimiter is a problem with whitespace inside numeric literals. That's hardly unique to whitespace: atuple = 5,6,7,8 vs atuple = 5,67,8 Look Ma, no whitespace! But even if allowing whitespace inside numeric literals did create a new avenue for errors which never existed before, it is a mistake to only consider the downside without the upside. In my opinion, that would be rather like declaring that the syntax for attribute access is a mistake because you might do this: x = MyClass() xy = 4 instead of this: x = MyClass() x.y = 4 At some point the programmer has to take responsibility for typos instead of blaming the syntax of the language. I agree that we should avoid syntax that *encourages* typos, but I don't believe that allowing whitespace inside numeric literals does that. -- Steven -- http://mail.python.org/mailman/listinfo/python-list
Re: Numeric literal syntax (was: Py 2.6 changes)
On Tue, 02 Sep 2008 11:13:27 +1000, Ben Finney wrote: > [EMAIL PROTECTED] writes: > >> For Python 2.7/3.1 I'd now like to write a PEP regarding the >> underscores into the number literals, like: 0b_0101_, 268_435_456 >> etc. > > +1 on such a capability. > > -1 on underscore as the separator. > > When you proposed this last year, the counter-proposal was made > http://groups.google.com/group/comp.lang.python/ msg/18123d100bba63b8?dmode=source> > to instead use white space for the separator, exactly as one can now do > with string literals. > > I don't see any good reason (other than your familiarity with the D > language) to use underscores for this purpose, and much more reason > (readability, consistency, fewer arbitrary differences in syntax, > perhaps simpler implementation) to use whitespace just as with string > literals. At the risk of bike-shedding, I think that allowing arbitrary whitespace between string literals is fine, because it aids readability to write this: do_something( "first part of the string" "another part of the string" "yet more of the string" "and a bit more" "and so on..." ) but I'm not sure that it is desirable to allow this: do_something( 142325 93.8012 7113 ) -1/2 on arbitrary whitespace, +1/2 on a single space, and +0 on underscores. If semi-colons didn't already have a use, I'd propose using them to break up numeric literals: 14;232;593.801;271;13 -- Steven -- http://mail.python.org/mailman/listinfo/python-list
Re: Numeric literal syntax
Ben Finney wrote: I would argue that the precedent, already within Python, for using a space to separate pieces of a string literal, is more important than precedents from other programming languages. that precedent also tells us that the whitespace approach is a common source of errors. taking an approach that's known to be error-prone and applying it to more cases isn't necessarily a great way to build a better language. -- http://mail.python.org/mailman/listinfo/python-list
Re: Numeric literal syntax
[EMAIL PROTECTED] writes: > Ben Finney: > > I don't see any good reason (other than your familiarity with the > > D language) to use underscores for this purpose, and much more > > reason (readability, consistency, fewer arbitrary differences in > > syntax, perhaps simpler implementation) to use whitespace just as > > with string literals. > > It's not just my familiarity, Ada language too uses underscore for > that purpose, I think, so there's a precedent, and Ada is a language > designed to always minimize programming errors, simple code mistakes > too. I would argue that the precedent, already within Python, for using a space to separate pieces of a string literal, is more important than precedents from other programming languages. > Consider: > > a = 125 125 125 > > a = 125, 125, 125 > > a = 125_125_125 > > For me the gestalt of the first line looks too much like the second > one, that is three separated things This is no more the case than for literal strings: a = "spam" "eggs" "ham" a = "spam", "eggs", "ham" Yet this is already a valid way in Python to specify, respectively, a single literal string and a literal tuple of strings. > While in the third case the _ helps glue the parts, creating a > single gestalt to my eyes. To my eyes, it's needlessly hard to read, and looks too similar to an identifier, not a literal. On the other hand, the spaces version is easy to see as analogous to the same syntax rules that already exist for strings. > Note that it's not just a matter of font and familiarity, it's also a > matter of brains. Your brain may be different from mine, so it may be > possible that what's better for you isn't better for me. So in such > situation a popular voting may be the only way to choose. But for me > having spaces to split number literals in parts is _worse_ than not > having any way at all to split them. So I'm strong opposed to your > suggestion, so I may not even propose the PEP if lot of people agrees > with your tastes. Thanks for making your position clear. -- \ “The WWW is exciting because Microsoft doesn't own it, and | `\ therefore, there's a tremendous amount of innovation | _o__) happening.” —Steve Jobs | Ben Finney -- http://mail.python.org/mailman/listinfo/python-list
Re: Numeric literal syntax (was: Py 2.6 changes)
Ben Finney: > I don't see any good reason (other than your familiarity with the D > language) to use underscores for this purpose, and much more reason > (readability, consistency, fewer arbitrary differences in syntax, > perhaps simpler implementation) to use whitespace just as with string > literals. It's not just my familiarity, Ada language too uses underscore for that purpose, I think, so there's a precedent, and Ada is a language designed to always minimize programming errors, simple code mistakes too. And another thing to consider is that they so far have given me zero problems... Consider: a = 125 125 125 a = 125, 125, 125 a = 125_125_125 For me the gestalt of the first line looks too much like the second one, that is three separated things (note that this is relative to the font you use, I am using a really good free font, Inconsolata, the very best I have found to program (better than Consolas) that separates things well). While in the third case the _ helps glue the parts, creating a single gestalt to my eyes. Note that it's not just a matter of font and familiarity, it's also a matter of brains. Your brain may be different from mine, so it may be possible that what's better for you isn't better for me. So in such situation a popular voting may be the only way to choose. But for me having spaces to split number literals in parts is _worse_ than not having any way at all to split them. So I'm strong opposed to your suggestion, so I may not even propose the PEP if lot of people agrees with your tastes. Bye, bearophile -- http://mail.python.org/mailman/listinfo/python-list
Numeric literal syntax (was: Py 2.6 changes)
[EMAIL PROTECTED] writes: > For Python 2.7/3.1 I'd now like to write a PEP regarding the > underscores into the number literals, like: 0b_0101_, 268_435_456 > etc. +1 on such a capability. -1 on underscore as the separator. When you proposed this last year, the counter-proposal was made http://groups.google.com/group/comp.lang.python/msg/18123d100bba63b8?dmode=source> to instead use white space for the separator, exactly as one can now do with string literals. I don't see any good reason (other than your familiarity with the D language) to use underscores for this purpose, and much more reason (readability, consistency, fewer arbitrary differences in syntax, perhaps simpler implementation) to use whitespace just as with string literals. -- \“When in doubt tell the truth. It will confound your enemies | `\ and astound your friends.” —Mark Twain, _Following the Equator_ | _o__) | Ben Finney -- http://mail.python.org/mailman/listinfo/python-list
