Underscores in Python numbers

[bearophileHUGS@lycos.com]

Re: Underscores in Python numbers

Steven D'Aprano:[color=blue]
> Perhaps Python should concatenate numeric literals at compile time:
> 123 456 is the same as 123456.[/color]

I think using the underscore it is more explicit:
n = 123_456

Alternatively the underscore syntax may be used to separate the number
from its base:
22875 == 22875_10 == 595b_16 == 123456_7
But probably this is less commonly useful (and not much explicit).

Bye,
bearophile

[bearophileHUGS@lycos.com]

Re: Underscores in Python numbers

Steven D'Aprano:[color=blue]
> Perhaps Python should concatenate numeric literals at compile time:
> 123 456 is the same as 123456.[/color]

I think using the underscore it is more explicit:
n = 123_456

Alternatively the underscore syntax may be used to separate the number
from its base:
22875 == 22875_10 == 595b_16 == 123456_7
But probably this is less commonly useful (and not much explicit).

Bye,
bearophile

[bonono@gmail.com]

Re: Underscores in Python numbers


Stefan Rank wrote:[color=blue]
> The other idea of teaching int() about separator characters has
> internationalis/zation issues:
> In many European countries, one would naturally try::
>
> int('500.000,23 ')
>
> instead of::
>
> int('500,000.23 ')[/color]

That is why I said

"Of course, also support the locale variant where the meaning of ","
and
"." is swapped in most European countries. "

We are seeing the same about base 2, 8, 10, 16.

May be :

int("E500.000,2 3")

as we are using :

0xffff

already for hex number

[bonono@gmail.com]

Re: Underscores in Python numbers


Stefan Rank wrote:[color=blue]
> The other idea of teaching int() about separator characters has
> internationalis/zation issues:
> In many European countries, one would naturally try::
>
> int('500.000,23 ')
>
> instead of::
>
> int('500,000.23 ')[/color]

That is why I said

"Of course, also support the locale variant where the meaning of ","
and
"." is swapped in most European countries. "

We are seeing the same about base 2, 8, 10, 16.

May be :

int("E500.000,2 3")

as we are using :

0xffff

already for hex number

[Steven D'Aprano]

Re: Underscores in Python numbers

On Sat, 19 Nov 2005 01:33:40 -0800, bearophileHUGS wrote:
[color=blue]
> Steven D'Aprano:[color=green]
>> Perhaps Python should concatenate numeric literals at compile time:
>> 123 456 is the same as 123456.[/color]
>
> I think using the underscore it is more explicit:
> n = 123_456[/color]

It is also easy to make a typo:

n = 123-456


--
Steven.

[Steven D'Aprano]

Re: Underscores in Python numbers

On Sat, 19 Nov 2005 01:33:40 -0800, bearophileHUGS wrote:
[color=blue]
> Steven D'Aprano:[color=green]
>> Perhaps Python should concatenate numeric literals at compile time:
>> 123 456 is the same as 123456.[/color]
>
> I think using the underscore it is more explicit:
> n = 123_456[/color]

It is also easy to make a typo:

n = 123-456


--
Steven.

[Sybren Stuvel]

Re: Underscores in Python numbers

bonono@gmail.co m enlightened us with:[color=blue]
> Of course, also support the locale variant where the meaning of ","
> and "." is swapped in most European countries.[/color]

This is exactly why I wouldn't use that notation. What happens if it
is hardcoded into the source? I mean, that's what we're talking about.
Then the program would have to have an indication of which locale is
used for which source file. Without that, a program would be
interpreted in a different way on different computers. I think that
would be rather messy.

I'm in favour of using spaces or underscores.

Sybren
--
The problem with the world is stupidity. Not saying there should be a
capital punishment for stupidity, but why don't we just take the
safety labels off of everything and let the problem solve itself?
Frank Zappa

[Sybren Stuvel]

Re: Underscores in Python numbers

bonono@gmail.co m enlightened us with:[color=blue]
> Of course, also support the locale variant where the meaning of ","
> and "." is swapped in most European countries.[/color]

This is exactly why I wouldn't use that notation. What happens if it
is hardcoded into the source? I mean, that's what we're talking about.
Then the program would have to have an indication of which locale is
used for which source file. Without that, a program would be
interpreted in a different way on different computers. I think that
would be rather messy.

I'm in favour of using spaces or underscores.

Sybren
--
The problem with the world is stupidity. Not saying there should be a
capital punishment for stupidity, but why don't we just take the
safety labels off of everything and let the problem solve itself?
Frank Zappa

[bonono@gmail.com]

Re: Underscores in Python numbers


Sybren Stuvel wrote:[color=blue]
> bonono@gmail.co m enlightened us with:[color=green]
> > Of course, also support the locale variant where the meaning of ","
> > and "." is swapped in most European countries.[/color]
>
> This is exactly why I wouldn't use that notation. What happens if it
> is hardcoded into the source? I mean, that's what we're talking about.
> Then the program would have to have an indication of which locale is
> used for which source file. Without that, a program would be
> interpreted in a different way on different computers. I think that
> would be rather messy.
>[/color]
As mentioned in another post, we have that situation in all other
places. Such as

mm/dd/yyyy vs dd/mm/yyyy
decimal("10.23" ) - would european people expect decimal("10,23" ) to
work ?
0xffff - a notation for base 16

why can't I have "E100.000,2 3" to mean "100,000.23 " ? Nothing but
notation.

[bonono@gmail.com]

Re: Underscores in Python numbers


Sybren Stuvel wrote:[color=blue]
> bonono@gmail.co m enlightened us with:[color=green]
> > Of course, also support the locale variant where the meaning of ","
> > and "." is swapped in most European countries.[/color]
>
> This is exactly why I wouldn't use that notation. What happens if it
> is hardcoded into the source? I mean, that's what we're talking about.
> Then the program would have to have an indication of which locale is
> used for which source file. Without that, a program would be
> interpreted in a different way on different computers. I think that
> would be rather messy.
>[/color]
As mentioned in another post, we have that situation in all other
places. Such as

mm/dd/yyyy vs dd/mm/yyyy
decimal("10.23" ) - would european people expect decimal("10,23" ) to
work ?
0xffff - a notation for base 16

why can't I have "E100.000,2 3" to mean "100,000.23 " ? Nothing but
notation.

[Roy Smith]

Re: Underscores in Python numbers

bearophileHUGS@ lycos.com wrote:[color=blue]
> Alternatively the underscore syntax may be used to separate the number
> from its base:
> 22875 == 22875_10 == 595b_16 == 123456_7
> But probably this is less commonly useful (and not much explicit).[/color]

We already have a perfectly good syntax for entering octal and hex
integers, because those are commonly used in many applications. There are,
on occasion, need for other bases, but they are so rare, specialized, and
non-standard (RFC-1924, for example, uses an interesting flavor of base-85)
that having syntax built into the language to support them would be
completely unjustified.

[Roy Smith]

Re: Underscores in Python numbers

bearophileHUGS@ lycos.com wrote:[color=blue]
> Alternatively the underscore syntax may be used to separate the number
> from its base:
> 22875 == 22875_10 == 595b_16 == 123456_7
> But probably this is less commonly useful (and not much explicit).[/color]

We already have a perfectly good syntax for entering octal and hex
integers, because those are commonly used in many applications. There are,
on occasion, need for other bases, but they are so rare, specialized, and
non-standard (RFC-1924, for example, uses an interesting flavor of base-85)
that having syntax built into the language to support them would be
completely unjustified.

[Steve Holden]

Re: Underscores in Python numbers

bonono@gmail.co m wrote:[color=blue]
> Stefan Rank wrote:
>[color=green]
>>The other idea of teaching int() about separator characters has
>>international is/zation issues:
>>In many European countries, one would naturally try::
>>
>> int('500.000,23 ')
>>
>>instead of::
>>
>> int('500,000.23 ')[/color]
>
>
> That is why I said
>
> "Of course, also support the locale variant where the meaning of ","
> and
> "." is swapped in most European countries. "
>
> We are seeing the same about base 2, 8, 10, 16.
>
> May be :
>
> int("E500.000,2 3")
>
> as we are using :
>
> 0xffff
>
> already for hex number
>[/color]
I really wouldn't want it to become possible to write Python code in one
locale that had to be edited before the numeric literals were valid in
another locale. That way madness lies.

regards
Steve
--
Steve Holden +44 150 684 7255 +1 800 494 3119
Holden Web LLC www.holdenweb.com
PyCon TX 2006 www.python.org/pycon/

[Steve Holden]

Re: Underscores in Python numbers

bonono@gmail.co m wrote:[color=blue]
> Stefan Rank wrote:
>[color=green]
>>The other idea of teaching int() about separator characters has
>>international is/zation issues:
>>In many European countries, one would naturally try::
>>
>> int('500.000,23 ')
>>
>>instead of::
>>
>> int('500,000.23 ')[/color]
>
>
> That is why I said
>
> "Of course, also support the locale variant where the meaning of ","
> and
> "." is swapped in most European countries. "
>
> We are seeing the same about base 2, 8, 10, 16.
>
> May be :
>
> int("E500.000,2 3")
>
> as we are using :
>
> 0xffff
>
> already for hex number
>[/color]
I really wouldn't want it to become possible to write Python code in one
locale that had to be edited before the numeric literals were valid in
another locale. That way madness lies.

regards
Steve
--
Steve Holden +44 150 684 7255 +1 800 494 3119
Holden Web LLC www.holdenweb.com
PyCon TX 2006 www.python.org/pycon/

[bearophileHUGS@lycos.com]

Re: Underscores in Python numbers

Roy Smith>We already have a perfectly good syntax for entering octal
and hex integers,

There is this syntax:
1536 == int("600", 16)
that accepts strings only, up to a base of 36.
There are the hex() and oct() functions.
There is the %x and %o sintax, that isn't easy to remember.
There are the 0x600 and 0600 syntaxes that probably look good only from
the point of view of a C programmer.
I think some cleaning up, with a simpler and more consistent and
general way of converting bases, can be positive. But probably no one
shares this point of view, and compatibility with C syntax is probably
positive, so you are right. I am still learning the correct way of
thinking in python.

Bye,
bearophile