From D

[bearophileHUGS]

There are various things I like about the D language that I think
Python too may enjoy. Here are few bits (mostly syntactical ones):

1) (we have discussed part of this in the past) You can put
underscores inside number literals, like 1_000_000, the compiler
doesn't enforce the position of such underscores, so you can also put
them like this: 1_00_000. You can put them in literals of decimals,
binary, hex, etc. I think it's quite useful, because when in Python
code I have a line like:
for i in xrange(1000000):
I need some time to count the zeros, because the lower levels of my
visual systems can't count/group them quickly (perceptually). While in
a syntax like:
for i in xrange(1_000_000):
my eyes help me group them at once.
2) Base 2 number literals, and base 2 "%b" printing with the writefln.
Base-2 numbers are less common in Python code, but once in a while I
use them. For example:
import std.stdio;
void main() {
auto x = 0b0100_0011;
writefln("%b", x);
writefln("%.8b", x);
writefln(x);
}
Prints:
1000011
01000011
67
3) All string literals are multi line. So you can write:
a = "how are
you";
There's no need for """ """.
4) With D I have created an xsplit() generator, and from my tests it's
quite faster than the split(), expecially if the string/lines you want
to split are few hundred chars long or more (it's not faster if you
want to split very little strings). So I think Python can enjoy such
string method too (you can probably simulate an xsplit with a regular
expression, but the same is true for some other string methods too).

Bye,
bearophile

[Stargaming]

On Tue, 24 Jul 2007 03:19:53 -0700, bearophileHUGS wrote:

There are various things I like about the D language that I think Python
too may enjoy. Here are few bits (mostly syntactical ones):

1) (we have discussed part of this in the past) You can put underscores
inside number literals, like 1_000_000, the compiler doesn't enforce the
position of such underscores, so you can also put them like this:
1_00_000. You can put them in literals of decimals, binary, hex, etc. I
think it's quite useful, because when in Python code I have a line like:
for i in xrange(1000000):
I need some time to count the zeros, because the lower levels of my
visual systems can't count/group them quickly (perceptually). While in a
syntax like:
for i in xrange(1_000_000):
my eyes help me group them at once.

Sounds like a good thing to be but the arbitrary positioning doesnt make
any sense. Additionally, I'd suggest 10**n in such cases (eg. 10**6).

2) Base 2 number literals, and base 2 "%b" printing with the writefln.
Base-2 numbers are less common in Python code, but once in a while I use
them. For example:
import std.stdio;
void main() {
auto x = 0b0100_0011;
writefln("%b", x);
writefln("%.8b", x);
writefln(x);
}
Prints:
1000011
01000011
67

Accepted. http://www.python.org/dev/peps/pep-3127/#abstract

3) All string literals are multi line. So you can write: a = "how are
you";
There's no need for """ """.

Well, I think it's just better to recognize visually. If you read ``foo =
"""...``, it's clear you can skip the next few lines because they're most
likely a chunk of data, not program code. Single quotation mark makes
clear this is just a very small token in the whole line. (Yes, there may
be exceptions, there may be syntax highlighting.)

4) With D I have created an xsplit() generator, and from my tests it's
quite faster than the split(), expecially if the string/lines you want
to split are few hundred chars long or more (it's not faster if you want
to split very little strings). So I think Python can enjoy such string
method too (you can probably simulate an xsplit with a regular
expression, but the same is true for some other string methods too).

Yea, that's a good idea -- fits into the current movement towards
generator'ing everything. But (IIRC) this idea came up earlier and there
has been a patch, too. A quick search at sf.net didn't turn up anything
relevant, tho.

Bye,
bearophile

Regards,
Stargaming

[Bjoern Schliessmann]

Stargaming wrote:

On Tue, 24 Jul 2007 03:19:53 -0700, bearophileHUGS wrote:

>While in a syntax like:
for i in xrange(1_000_000):
my eyes help me group them at once.

Sounds like a good thing to be but the arbitrary positioning
doesnt make any sense.

Checking underscore positions would only add complexity. Why not
just ignore them, no matter where they are?

Additionally, I'd suggest 10**n in such cases (eg. 10**6).

This fails if you happen to have more than only zeros at the right
side.

Regards,
Björn

--
BOFH excuse #97:

Small animal kamikaze attack on power supplies

[Steven D'Aprano]

On Tue, 24 Jul 2007 20:09:00 +0200, Bjoern Schliessmann wrote:

Stargaming wrote:

>On Tue, 24 Jul 2007 03:19:53 -0700, bearophileHUGS wrote:

>>While in a syntax like:
for i in xrange(1_000_000):
my eyes help me group them at once.

Sounds like a good thing to be but the arbitrary positioning
doesnt make any sense.

Checking underscore positions would only add complexity. Why not
just ignore them, no matter where they are?

Underscores in numerics are UGLY. Why not take a leaf out of implicit
string concatenation and allow numeric literals to implicitly concatenate?

Python already does:
"hello-" "world" ="hello-world"

Propose:
123 456 789 =123456789
123.456 789 =123.456789
--
Steven.

[Eric_Dexter]

On Jul 24, 5:19 am, [e-mail] wrote:

There are various things I like about the D language that I think
Python too may enjoy. Here are few bits (mostly syntactical ones):

1) (we have discussed part of this in the past) You can put
underscores inside number literals, like 1_000_000, the compiler
doesn't enforce the position of such underscores, so you can also put
them like this: 1_00_000. You can put them in literals of decimals,
binary, hex, etc. I think it's quite useful, because when in Python
code I have a line like:
for i in xrange(1000000):
I need some time to count the zeros, because the lower levels of my
visual systems can't count/group them quickly (perceptually). While in
a syntax like:
for i in xrange(1_000_000):
my eyes help me group them at once.

2) Base 2 number literals, and base 2 "%b" printing with the writefln.
Base-2 numbers are less common in Python code, but once in a while I
use them. For example:
import std.stdio;
void main() {
auto x = 0b0100_0011;
writefln("%b", x);
writefln("%.8b", x);
writefln(x);}

Prints:
1000011
01000011
67

3) All string literals are multi line. So you can write:
a = "how are
you";
There's no need for """ """.

4) With D I have created an xsplit() generator, and from my tests it's
quite faster than the split(), expecially if the string/lines you want
to split are few hundred chars long or more (it's not faster if you
want to split very little strings). So I think Python can enjoy such
string method too (you can probably simulate an xsplit with a regular
expression, but the same is true for some other string methods too).

Bye,
bearophile

I think there is a language bridge so that you can compile d for
python.. looks realy easy but I have python 2.5 and panda and it
try's to go for the panda instalation. It looks much easier than c to
use with python in fact.. I don't know if that would change the speed
of it
though to be in a library.

https://sourceforge.net/projects/dex-tracker

[Gabriel Genellina]

En Tue, 24 Jul 2007 11:10:53 -0300, Stargaming <st********@gmail.com>
escribió:

On Tue, 24 Jul 2007 03:19:53 -0700, bearophileHUGS wrote:

>There are various things I like about the D language that I think Python
too may enjoy. Here are few bits (mostly syntactical ones):

1) (we have discussed part of this in the past) You can put underscores
inside number literals, like 1_000_000, the compiler doesn't enforce the
position of such underscores, so you can also put them like this:
1_00_000. You can put them in literals of decimals, binary, hex, etc. I

Sounds like a good thing to be but the arbitrary positioning doesnt make
any sense. Additionally, I'd suggest 10**n in such cases (eg. 10**6).

Why not? Because in English major numbers are labeled in thousands?
(thousand, million, billion...)
In India, they're grouped by two after the first thousand; in China,
they're grouped each 4 digits (that is, there is a single word for "ten
thousands" = wan4 = 万, and the next required word is for 10**8 = yi4 = 亿)

--
Gabriel Genellina

[Jakub Stolarski]

On Jul 25, 1:08 am, Steven D'Aprano
<[e-mail]:

Underscores in numerics are UGLY. Why not take a leaf out of implicit
string concatenation and allow numeric literals to implicitly concatenate?

Python already does:
"hello-" "world" ="hello-world"

Propose:
123 456 789 =123456789
123.456 789 =123.456789

I like that.

[Wildemar Wildenburger]

Steven D'Aprano wrote:

Python already does:
"hello-" "world" ="hello-world"

Propose:
123 456 789 =123456789
123.456 789 =123.456789

I second that!

/W

[mensanator]

On Jul 24, 6:08 pm, Steven D'Aprano
<[e-mail]:

On Tue, 24 Jul 2007 20:09:00 +0200, Bjoern Schliessmann wrote:

Stargaming wrote:

On Tue, 24 Jul 2007 03:19:53 -0700, bearophileHUGS wrote:

>While in a syntax like:
for i in xrange(1_000_000):
my eyes help me group them at once.

Sounds like a good thing to be but the arbitrary positioning
doesnt make any sense.

Checking underscore positions would only add complexity. Why not
just ignore them, no matter where they are?

Underscores in numerics are UGLY. Why not take a leaf out of implicit
string concatenation and allow numeric literals to implicitly concatenate?

Python already does:
"hello-" "world" ="hello-world"

Propose:
123 456 789 =123456789
123.456 789 =123.456789

So, spaces will no longer be delimiters? Won't that cause
much wailing and gnashing of teeth?

>
--
Steven.

[Paddy]

On Jul 25, 1:47 am, "Gabriel Genellina" <[e-mail]>
wrote:

En Tue, 24 Jul 2007 11:10:53 -0300, Stargaming <[e-mail]>
escribió:

On Tue, 24 Jul 2007 03:19:53 -0700, bearophileHUGS wrote:

There are various things I like about the D language that I think Python
too may enjoy. Here are few bits (mostly syntactical ones):

1) (we have discussed part of this in the past) You can put underscores
inside number literals, like 1_000_000, the compiler doesn't enforce the
position of such underscores, so you can also put them like this:
1_00_000. You can put them in literals of decimals, binary, hex, etc. I

Sounds like a good thing to be but the arbitrary positioning doesnt make
any sense. Additionally, I'd suggest 10**n in such cases (eg. 10**6).

Why not? Because in English major numbers are labeled in thousands?
(thousand, million, billion...)
In India, they're grouped by two after the first thousand; in China,
they're grouped each 4 digits (that is, there is a single word for "ten
thousands" = wan4 = , and the next required word is for 10**8 = yi4 = )

--
Gabriel Genellina

But then,what would _0 be, the number 0 or the name _0 analagous to
a0

- Pad.

[Marc 'BlackJack' Rintsch]

On Wed, 25 Jul 2007 10:47:33 -0700, Paddy wrote:

But then,what would _0 be, the number 0 or the name _0 analagous to
a0

Of course the name because numbers have to start with a digit or a dot.
Otherwise this would break backwards compatibility.

Ciao,
Marc 'BlackJack' Rintsch

[Ben Finney]

"me********@aol.com" <me********@aol.comwrites:

On Jul 24, 6:08 pm, Steven D'Aprano
<[e-mail]:

Python already does:
"hello-" "world" ="hello-world"

Propose:
123 456 789 =123456789
123.456 789 =123.456789

So, spaces will no longer be delimiters?

I don't see how you get that conclusion from Steven's proposal. If the
latter implied that "spaces will no longer be delimiters", then surely
the former must also imply that.

The former already exists, spaces are still delimiters when syntax
allows, so your conclusion is baseless.

--
\ "I got food poisoning today. I don't know when I'll use it." |
`\ -- Steven Wright |
_o__) |
Ben Finney

[mensanator]

On Jul 25, 8:00 pm, Ben Finney <[e-mail]>
wrote:

"[e-mail]" <[e-mail]:

On Jul 24, 6:08 pm, Steven D'Aprano
<[e-mail]:

Python already does:
"hello-" "world" ="hello-world"

Propose:
123 456 789 =123456789
123.456 789 =123.456789

So, spaces will no longer be delimiters?

I don't see how you get that conclusion from Steven's proposal.

IDLE 1.2c1

>>s = '123 456'
s.split()

['123', '456']

The only way to get '123 456' would be to treat a space as a
non-delimiter. But what if those actually WERE two different numbers?

If the
latter implied that "spaces will no longer be delimiters", then surely
the former must also imply that.

The former already exists, spaces are still delimiters when syntax
allows, so your conclusion is baseless.

--
\ "I got food poisoning today. I don't know when I'll use it." |
`\ -- Steven Wright |
_o__) |
Ben Finney

[Steven D'Aprano]

On Wed, 25 Jul 2007 10:22:46 -0700, me********@aol.com wrote:

On Jul 24, 6:08 pm, Steven D'Aprano
<[e-mail]:

>On Tue, 24 Jul 2007 20:09:00 +0200, Bjoern Schliessmann wrote:

Stargaming wrote:
On Tue, 24 Jul 2007 03:19:53 -0700, bearophileHUGS wrote:

>>While in a syntax like:
for i in xrange(1_000_000):
my eyes help me group them at once.

>Sounds like a good thing to be but the arbitrary positioning
doesnt make any sense.

Checking underscore positions would only add complexity. Why not
just ignore them, no matter where they are?

Underscores in numerics are UGLY. Why not take a leaf out of implicit
string concatenation and allow numeric literals to implicitly concatenate?

Python already does:
"hello-" "world" ="hello-world"

Propose:
123 456 789 =123456789
123.456 789 =123.456789

So, spaces will no longer be delimiters? Won't that cause
much wailing and gnashing of teeth?

Did you miss the bit where Python ALREADY does this for strings?

Yes, whitespace will still delimit tokens. No, it won't be a problem,
because two int tokens can be "concatenated" to make a single int token,
exactly as happens for strings.

(I say "no problem", but of course I don't know how much _actual_ coding
effort will be needed to Make This Work. It might be a little, it might be
a lot.)

Currently, 234 567 is a syntax error in Python, so there are no problems
with backward compatibility or breaking code that relies on the meaning of
whitespace between two ints.
--
Steven

[Steven D'Aprano]

On Wed, 25 Jul 2007 18:17:19 -0700, me********@aol.com wrote:

On Jul 25, 8:00 pm, Ben Finney <[e-mail]>
wrote:

>"[e-mail]" <[e-mail]:

On Jul 24, 6:08 pm, Steven D'Aprano
<[e-mail]:
Python already does:
"hello-" "world" ="hello-world"

Propose:
123 456 789 =123456789
123.456 789 =123.456789

So, spaces will no longer be delimiters?

I don't see how you get that conclusion from Steven's proposal.

IDLE 1.2c1

>>>s = '123 456'
s.split()

['123', '456']

The only way to get '123 456' would be to treat a space as a
non-delimiter. But what if those actually WERE two different numbers?

That makes no sense at all. Your example is about splitting a _string_.
You can construct and split the string any way you like:

>>s = '123SURPRISE456'
s.split('SURPRISE')

['123', '456']

Notice that the results aren't ints, they are strings.

To get an int literal, you currently type something like 123456. 123 456
is currently not valid in Python, it raises an SyntaxError. Try it for
yourself:

>>123 456

File "<stdin>", line 1
123 456
^
SyntaxError: invalid syntax

If you want two numbers, you would do exactly the same thing you would now:

>>x, y = 123, 456
print "x is %d and y is %d" % (x, y)

x is 123 and y is 456

--
Steven.

[mensanator]

On Jul 25, 8:54?pm, Steven D'Aprano
<[e-mail]:

On Wed, 25 Jul 2007 10:22:46 -0700, [e-mail] wrote:

On Jul 24, 6:08 pm, Steven D'Aprano
<[e-mail]:

On Tue, 24 Jul 2007 20:09:00 +0200, Bjoern Schliessmann wrote:
Stargaming wrote:
On Tue, 24 Jul 2007 03:19:53 -0700, bearophileHUGS wrote:

>While in a syntax like:
for i in xrange(1_000_000):
my eyes help me group them at once.

Sounds like a good thing to be but the arbitrary positioning
doesnt make any sense.

Checking underscore positions would only add complexity. Why not
just ignore them, no matter where they are?

Underscores in numerics are UGLY. Why not take a leaf out of implicit
string concatenation and allow numeric literals to implicitly concatenate?

Python already does:
"hello-" "world" ="hello-world"

Propose:
123 456 789 =123456789
123.456 789 =123.456789

So, spaces will no longer be delimiters? Won't that cause
much wailing and gnashing of teeth?

Did you miss the bit where Python ALREADY does this for strings?

Did you miss the bit where I agreed this was a GOOD feature?
You didn't miss it because I didn't say it.

>
Yes, whitespace will still delimit tokens. No, it won't be a problem,
because two int tokens can be "concatenated" to make a single int token,
exactly as happens for strings.

Any number of whitespace characters? Just spaces or all
whitespace characters?

>
(I say "no problem", but of course I don't know how much _actual_ coding
effort will be needed to Make This Work. It might be a little, it might be
a lot.)

Currently, 234 567 is a syntax error in Python, so there are no problems
with backward compatibility or breaking code that relies on the meaning of
whitespace between two ints.

That's the ONLY issue? What about searching source
code files? What's the regular expression for
locating a number with an arbitrary number of digits
seperated into an arbitrary number of blocks of an
arbitray number of digits with an arbitrary number
of whitespace characters between each block?

>
--
Steven

[Ben Finney]

"me********@aol.com" <me********@aol.comwrites:

IDLE 1.2c1

>s = '123 456'
s.split()

['123', '456']

The str.split method has no bearing on this discussion, which is about
the Python language syntax, and numeric literal values in particular.

--
\ "Pinky, are you pondering what I'm pondering?" "Wuh, I think |
`\ so, Brain, but burlap chafes me so." -- _Pinky and The Brain_ |
_o__) |
Ben Finney

[Ben Finney]

"me********@aol.com" <me********@aol.comwrites:

On Jul 25, 8:54?pm, Steven D'Aprano
<[e-mail]:
Any number of whitespace characters? Just spaces or all whitespace
characters?

What about searching source code files? What's the regular
expression for locating a number with an arbitrary number of digits
seperated into an arbitrary number of blocks of an arbitray number
of digits with an arbitrary number of whitespace characters between
each block?

These issues all exist for implicitly concatenated string literals. It
seems the same rules would apply; that would both make sense from an
implementation standpoint, and result in consistency for the Python
programmer too.

--
\ "Are you pondering what I'm pondering?" "I think so, Brain, but |
`\ wouldn't his movies be more suitable for children if he was |
_o__) named Jean-Claude van Darn?" -- _Pinky and The Brain_ |
Ben Finney

[bearophileHUGS]

Sorry for the slow feedback.

Stargaming>Sounds like a good thing to be but the arbitrary
positioning doesnt make any sense.<

The arbitrary positioning allows you to denote 4-digit groups too in
binary/hex literals, like in my example:
auto x = 0b0100_0011;
Stargaming>fits into the current movement towards generator'ing
everything. But (IIRC) this idea came up earlier and there has been a
patch, too.<

Python is old so most simple ideas aren't new :-)
Steven D'Aprano>Underscores in numerics are UGLY.<

I presume it's a matter of taste too. I use them often in D code, and
the _ symbol is very different from the 0..F/0..f digits so you can
tell them apart with no problems.
Steven D'Aprano>Why not take a leaf out of implicit string
concatenation and allow numeric literals to implicitly concatenate?<

The "_" helps my eyes see that those digit groups are part of the same
number. With spaces I think my eyes may need a bit of extra time to
decide if they are parts of the same number literal.
Eric Dexter>I think there is a language bridge so that you can compile
d for python.. looks realy easy but I have python 2.5 and panda and
it try's to go for the panda instalation. It looks much easier than c
to use with python in fact..<

Are you talking about "Pyd"? It's a good bridge, and I like it. It's
actively updated, soon in version 1.0.

Bye,
bearophile

[Paul Rubin]

Steven D'Aprano <st***@REMOVE.THIS.cybersource.com.auwrites:

Propose:
123 456 789 =123456789
123.456 789 =123.456789

+1

[Leo Petr]

On Jul 24, 10:10 am, Stargaming <[e-mail]:

On Tue, 24 Jul 2007 03:19:53 -0700, bearophileHUGS wrote:

There are various things I like about the D language that I think Python
too may enjoy. Here are few bits (mostly syntactical ones):

1) (we have discussed part of this in the past) You can put underscores
inside number literals, like 1_000_000, the compiler doesn't enforce the
position of such underscores, so you can also put them like this:
1_00_000. You can put them in literals of decimals, binary, hex, etc. I
think it's quite useful, because when in Python code I have a line like:
for i in xrange(1000000):
I need some time to count the zeros, because the lower levels of my
visual systems can't count/group them quickly (perceptually). While in a
syntax like:
for i in xrange(1_000_000):
my eyes help me group them at once.

Sounds like a good thing to be but the arbitrary positioning doesnt make
any sense. Additionally, I'd suggest 10**n in such cases (eg. 10**6).

http://blogs.msdn.com/oldnewthing/ar...17/577483.aspx

Digits are grouped in 2s in India and in 4s in China and Japan.

Regards,

Leons Petrazickis
http://lpetr.org/blog/

[mensanator]

On Jul 26, 12:18 am, Ben Finney <[e-mail]>
wrote:

"[e-mail]" <[e-mail]:

IDLE 1.2c1

>>s = '123 456'
>>s.split()

['123', '456']

The str.split method has no bearing on this discussion,

It most certainly does. To make '123 456' into an integer,
you split it and then join it.

>>z = '123 456'
y = z.split()
x = ''.join(y)
w = int(x)
w

123456

Just wanted to be sure that this must still be done explicitly
and that the language won't do it for me behind my back.

which is about
the Python language syntax,

Provided it is confined to the language syntax.

and numeric literal values in particular.

Fine, as long as int('123 456') continues to be an error.

>
--
\ "Pinky, are you pondering what I'm pondering?" "Wuh, I think |
`\ so, Brain, but burlap chafes me so." -- _Pinky and The Brain_ |
_o__) |
Ben Finney

[Kay Schluehr]

On Jul 25, 7:22 pm, "[e-mail]" <[e-mail]:

On Jul 24, 6:08 pm, Steven D'Aprano

<[e-mail]:

On Tue, 24 Jul 2007 20:09:00 +0200, Bjoern Schliessmann wrote:

Stargaming wrote:
>On Tue, 24 Jul 2007 03:19:53 -0700, bearophileHUGS wrote:

>>While in a syntax like:
>>for i in xrange(1_000_000):
>>my eyes help me group them at once.

>Sounds like a good thing to be but the arbitrary positioning
>doesnt make any sense.

Checking underscore positions would only add complexity. Why not
just ignore them, no matter where they are?

Underscores in numerics are UGLY. Why not take a leaf out of implicit
string concatenation and allow numeric literals to implicitly concatenate?

Python already does:
"hello-" "world" ="hello-world"

Propose:
123 456 789 =123456789
123.456 789 =123.456789

So, spaces will no longer be delimiters? Won't that cause
much wailing and gnashing of teeth?

Nope. Just replace the current grammar rule

atom: ... NAME | STRING+ | NUMBER

by

atom: ... NAME | STRING+ | NUMBER+

The resulting grammar is still free of ambiguities. The tokenizer
doesn't complain anyway - not even yet.

[Ryan Ginstrom]

On Behalf Of Leo Petr

Digits are grouped in 2s in India and in 4s in China and Japan.

This is not entirely true in Japan's case. When written without Japanese
characters, Japan employs the same format as the US, for example:

1,000,000
(However, they would read this as $BI4K|(B (hyaku man), literally 100 ten
thousands.)

Raymond is correct in that Japan traditionally groups in fours (and stills
reads it that way regardless, as shown above), but in an ordinary
programming context, this almost never comes into play.

On the original topic of the thread, I personally like the underscore idea
from D, and I like it better than the "concatenation" idea, even though I
agree that it is more consistent with Python's string-format rules.

Regards,
Ryan Ginstrom

[Tim Williams]

On 26/07/07, me********@aol.com <me********@aol.comwrote:

>The str.split method has no bearing on this discussion,

It most certainly does. To make '123 456' into an integer,
you split it and then join it.

>z = '123 456'
y = z.split()
x = ''.join(y)
w = int(x)
w

123456

.....but it doesn't if you use replace !! <wink>

>>z = '123 456'
int( z.replace( ' ' ,'' ) )

123456

Propose:
123 456 789 =123456789
123.456 789 =123.456789

+1 for me too

--

Tim Williams

[Ben Finney]

"me********@aol.com" <me********@aol.comwrites:

So, just as

>>int('123' '456')

123456

is not an error, the proposal is that

>>a = 123 456

SyntaxError: invalid syntax

will not be an error either.

More directly: Just as these three statements create the same literal
value:

>>'abc' 'def'

'abcdef'

>>'ab' 'cd' 'ef'

'abcdef'

>>'abcdef'

'abcdef'

the proposal is that these three statements create the same literal
value:

>>12 345.678 90

12345.67890

>>12 3456.78 90

12345.67890

>>12345.67890

12345.67890

and not be a syntax error.

Yet,

>>a = int('123 456')

Traceback (most recent call last):
File "<pyshell#7>", line 1, in <module>
a = int('123 456')
ValueError: invalid literal for int() with base 10: '123 456'

will still be an error.

Since that value, '123 456', is one that is rejected by the 'int'
constructor. Nothing to do with this proposal.

Just trying to be clear on this. Wouldn't want that syntax behavior
to carry over into run-time.

The distinction you need to be clear on is between the Python syntax
for writing literal values in code (which is proposed to change by
this), and the behaviour of operations on arbitrary values at runtime
(which is outside the scope of this proposal).

--
\ "I bought a dog the other day. I named him Stay. It's fun to |
`\ call him. 'Come here, Stay! Come here, Stay!' He went insane. |
_o__) Now he just ignores me and keeps typing." -- Steven Wright |
Ben Finney

[Ben Finney]

"me********@aol.com" <me********@aol.comwrites:

The str.split method has no bearing on this discussion,

It most certainly does. To make '123 456' into an integer,
you split it and then join it.

Indeed. Which has nothing to do with the Python syntax for creating a
numeric literal in code.

--
\ "God forbid that any book should be banned. The practice is as |
`\ indefensible as infanticide." -- Dame Rebecca West |
_o__) |
Ben Finney

[fdu.xiaojf]

Gabriel Genellina wrote:

En Tue, 24 Jul 2007 11:10:53 -0300, Stargaming <st********@gmail.com>
escribió:

>On Tue, 24 Jul 2007 03:19:53 -0700, bearophileHUGS wrote:

>>There are various things I like about the D language that I think Python
too may enjoy. Here are few bits (mostly syntactical ones):

1) (we have discussed part of this in the past) You can put underscores
inside number literals, like 1_000_000, the compiler doesn't enforce the
position of such underscores, so you can also put them like this:
1_00_000. You can put them in literals of decimals, binary, hex, etc. I

Sounds like a good thing to be but the arbitrary positioning doesnt make
any sense. Additionally, I'd suggest 10**n in such cases (eg. 10**6).

Why not? Because in English major numbers are labeled in thousands?
(thousand, million, billion...)
In India, they're grouped by two after the first thousand; in China,
they're grouped each 4 digits (that is, there is a single word for "ten
thousands" = wan4 = 万, and the next required word is for 10**8 = yi4 = 亿)

Yes, in China numbers are grouped each 4 digits while it is different in
other countries, so I think it would be better if we could put arbitrary white
spaces inside number literals.

[Alex Martelli]

me********@aol.com <me********@aol.comwrote:

code files? What's the regular expression for
locating a number with an arbitrary number of digits
seperated into an arbitrary number of blocks of an
arbitray number of digits with an arbitrary number
of whitespace characters between each block?

For a decimal integer (or octal) number, I'd use something similar to:
r'\d[\d\s]+'

This also gets trailing whitespace, but that shouldn't be much of a
problem in most practical cases. Of course, just like today, it becomes
a bit hairier if you also want to find hex, oct (to be 0o777 in the
future), other future notations such as binary, floats, complex numbers,
&c:-) -- but the simple fact that a [\d\s] is accepted where today only
a \d would be, per se, would not contribute to that hair in any
significant way, it seems to me.
Alex