[Python-Dev] PEP 515: Underscores in Numeric Literals

[Glenn Linderman]

On 2/12/2016 12:06 PM, Chris Barker wrote:
> On Fri, Feb 12, 2016 at 1:00 AM, Paul Moore <p.f.moore at gmail.com 
> <mailto:p.f.moore at gmail.com>> wrote:
>
>
>     I have no opinion on anything other than that whatever syntax is
>     implemented as long as it allows single underscores between digits,
>     such as
>
>     1_000_000
>
>     Everything else is irrelevant to me, and if I read code that uses
>     anything else, I'd judge it based on readability and style, and
>     wouldn't care about arguments that "it's allowed by the grammar".
>
>
> I totally agree -- and it's clear that other cultures group digits 
> differently, so we should allow that, but while I'll live with it 
> either way, I'd rather have it be as restrictive as possible rather 
> than as unrestricted as possible. As in:
>
> no double underscores

Useful for really long binary constants... one _ for nybble or field 
divisions, two __ for byte divisions.

Of course, really long binary constants might be a bad idea.

> no underscore right before or after a period
> no underscore at the beginning or end.

You get your wish for the beginning... it would be ambiguous with 
identifiers. And your style guide can include whatever restrictions you 
like, for your code.

> ....
>
> As Paul said, as long as I can do the above, I'll be fine, but I think 
> everyone's source code will be a lot cleaner in the long run if you 
> don't have the option of doing who knows what weird arrangement....
>
> As for the SS# example -- it seems a bad idea to me to store a SS# 
> number as an integer anyway -- so all the weird IDs etc. formats 
> aren't really relevant...

SS#... why not integer?  Phone#... why not integer? There's a lot of 
nice digit-division conventions for phone#s in different parts of the world.

The only ambiguity is if such numbers have leading zeros, you have to 
"know" (or record) how many total digits are expected.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20160212/ec8778f2/attachment.html>