On Feb 10, 2016, at 16:21, Steven D'Aprano <st...@pearwood.info> wrote: > >> On Wed, Feb 10, 2016 at 03:45:48PM -0800, Andrew Barnert via Python-Dev >> wrote: >> On Feb 10, 2016, at 14:20, Georg Brandl <g.bra...@gmx.net> wrote: >> >> First, general questions: should the PEP mention the Decimal constructor? >> What about int and float (I'd assume int(s) continues to work as always, >> while int(s, 0) gets the new behavior, but if that isn't obviously true, it >> may be worth saying explicitly). >> >>> * Trailing underscores are not allowed, because they look confusing and >>> don't >>> contribute much to readability. >> >> Why is "123_456_" so ugly that we have to catch it, when >> "1___2_345______6" is just fine, > > It's not just fine, it's ugly as sin, but it shouldn't be a matter for > the parser to decide a style-issue.
Exactly. So why should it be any more of a matter for the parser to decide that "123_456_" is illegal? Leave that in the style guide, and keep the parser, and the reference documentation, as simple as possible. >> or "123e__+456"? > > That I would prohibit. The PEP allows that. The simpler rule used by Swift and Rust prohibits it. >> More to the point, >> if we really need an extra rule, and more complicated BNF, to outlaw >> this case, I don't think we want a liberal design at all. > > I think "underscores can occur between any two digits" is pretty > liberal, since it allows multiple underscores, and allows grouping in > any size group (including mixed sizes, and stupid sizes like 1). The PEP calls that a type-2 conservative proposal, and uses "liberal" to mean that underscores can appear in places that aren't between digits. I don't think we want that liberalism, especially if it requires 5 rules instead of 1 to get it right. Again, Swift and Rust only allow underscores in the digit part of integers, and the up to three digit parts of floats, and the only rule they impose is no leading underscore. (In some caass they lead to ambiguity, in others they don't, but it's easier to just always ban them.) I don't see anything wrong with that rule. The fact that it doesn't allow "1.2e_+3" seems fine. The fact that it doesn't prevent "123_" seems fine also. It's not about being as liberal as possible, or as restrictive as possible, because those edge cases just don't matter, so being as simple as possible seems like an obvious win. >> Also, notice that Swift, Rust, and D all show examples with trailing >> underscores in their references, and they don't look particularly out >> of place with the other examples. > > That's a matter of opinion. Sure, but it's apparently the opinion of the people who designed and/or documented this feature in three out of the four languages I looked at (aka every language but Perl), not mine. And honestly, are you really claiming that in your opinion, "123_456_" is worse than all of their other examples, like "1_23__4"? They're both presented as something the syntax allows, and neither one looks like something I'd ever want to write, much less promote in a style guide or something, but neither one screams out as something that's so heinous we need to complicate the language to ensure it raises a SyntaxError. Yes, that's my opinion, but do.you really have a different opinion about any part of that? _______________________________________________ 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
