Great PEP overall. We definitely don't want the restriction to grouping numbers only in threes. South Asian crore use grouping in twos.
https://en.m.wikipedia.org/wiki/Crore On Feb 11, 2016 7:04 PM, "Glenn Linderman" <v+pyt...@g.nevcal.com> wrote: > On 2/11/2016 4:16 PM, Steven D'Aprano wrote: > > On Thu, Feb 11, 2016 at 06:03:34PM +0000, Brett Cannon wrote: > > On Thu, 11 Feb 2016 at 02:13 Steven D'Aprano <st...@pearwood.info> > <st...@pearwood.info> wrote: > > > On Wed, Feb 10, 2016 at 08:41:27PM -0800, Andrew Barnert wrote: > > > And honestly, are you really claiming that in your opinion, "123_456_" > is worse than all of their other examples, like "1_23__4"? > > > Yes I am, because 123_456_ looks like you've forgotten to finish typing > the last group of digits, while 1_23__4 merely looks like you have no > taste. > > > > OK, but the keyword in your sentence is "taste". > > > I disagree. The key *idea* in my sentence is that the trailing > underscore looks like a programming error. In my opinion, avoiding that > impression is important enough to make trailing underscores a syntax > error. > > I've seen a few people vote +1 for things like 123_j and 1.23_e99, but I > haven't seen anyone in favour of trailing underscores. Does anyone think > there is a good case for allowing trailing underscores? > > > > If we update PEP 8 for our > needs to say "Numerical literals should not have multiple underscores in a > row or have a trailing underscore" then this is taken care of. We get a > dead-simple rule for when underscores can be used, the implementation is > simple, and we get to have more tasteful usage in the stdlib w/o forcing > our tastes upon everyone or complicating the rules or implementation. > > > I think this is a misrepresentation of the alternative. As I see it, we > have two alternatives: > > - one or more underscores can appear AFTER the base specifier or any digit; > - one or more underscores can appear BETWEEN two digits. > > To describe the second alternative as "complicating the rules" is, I > think, grossly unfair. And if Serhiy's proposal is correct, the > implementation is also no more complicated: > > # underscores after digits > octinteger: "0" ("o" | "O") "_"* octdigit (octdigit | "_")* > hexinteger: "0" ("x" | "X") "_"* hexdigit (hexdigit | "_")* > bininteger: "0" ("b" | "B") "_"* bindigit (bindigit | "_")* > > > # underscores after digits > octinteger: "0" ("o" | "O") (octdigit | "_")* > hexinteger: "0" ("x" | "X") (hexdigit | "_")* > bininteger: "0" ("b" | "B") (bindigit | "_")* > > > An extra side effect is that there are more ways to write zero. 0x, 0b, > 0o, 0X, 0B, 0O, 0x_, 0b_, 0o_, etc. > But most people write 0 anyway, so those would be bad style, anyway, > but it makes the implementation simpler. > > > > # underscores between digits > octinteger: "0" ("o" | "O") octdigit (["_"] octdigit)* > hexinteger: "0" ("x" | "X") hexdigit (["_"] hexdigit)* > bininteger: "0" ("b" | "B") bindigit (["_"] bindigit)* > > > The idea that the second alternative "forc[es] our tastes on everyone" > while the first does not is bogus. The first alternative also prohibits > things which are a matter of taste: > > # prohibited in both alternatives > 0_xDEADBEEF > 0._1234 > 1.2e_99 > -_1 > 1j_ > > > I think that there is broad agreement that: > > - the basic idea is sound > - leading underscores followed by digits are currently legal > identifiers and this will not change > - underscores should not follow the sign - + > - underscores should not follow the decimal point . > - underscores should not follow the exponent e|E > - underscores will not be permitted inside the exponent (even if > it is harmless, it's silly to write 1.2e9_9) > - underscores should not follow the complex suffix j > > and only minor disagreement about: > > - whether or not underscores will be allowed after the base > specifier 0x 0o 0b > > > +1 to allow underscores after the base specifier. > > - whether or not underscores will be allowed before the decimal > point, exponent and complex suffix. > > > +1 to allow them. There may be cases where they are useful, and if it is > not useful, it would not be used. I really liked someone's style guide > proposal: use of underscore within numeric constants should only be done to > aid readability. However, pre-judging what aids readability to one > person's particular taste is inappropriate. > > Can we have a show of hands, in favour or against the above two? And > then perhaps Guido can rule on this one way or the other and we can get > back to arguing about more important matters? :-) > > In case it isn't obvious, I prefer to say No to allowing underscores > after the base specifier, or before the decimal point, exponent and > complex suffix. > > I think it was obvious :) And I think we disagree. And yes, there are > more important matters. But it was just a couple days ago when I wrote a > big constant in some new code that I was thinking how nice it would be if I > could put a delimiter in there... so I'll be glad for the feature when it > is available. > > _______________________________________________ > Python-Dev mailing list > Python-Dev@python.org > https://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > https://mail.python.org/mailman/options/python-dev/mertz%40gnosis.cx > >
_______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com