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]

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]

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

 

[Steven D'Aprano]

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

 

[Eric_Dexter]

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]

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 = 亿)

 

[Jakub Stolarski]

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]

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

Propose:
123 456 789 => 123456789
123.456 789 => 123.456789

I second that!

/W

 

[mensanator]

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?

 

[Paddy]

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 = )

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

- Pad.

 

[star.public]

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

I can't think of a circumstance in which

48 1906

is valid, so . . .

I like it, too

 

[Marc 'BlackJack' Rintsch]

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]

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.

 

[mensanator]

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

IDLE 1.2c1['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?

 

[Steven D'Aprano]

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 D'Aprano]

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

IDLE 1.2c1['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:
['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:
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 is 123 and y is 456

 

[mensanator]

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?

 

[mensanator]

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_.

Why does it make no sense? Have you never had to
scrape a web page or read a CSV file?

You can construct and split the string any way you like:

['123', '456']

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

Duh. I took for granted you knew how to convert
an string to an integer.

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:

So this proposal would only apply to string literals
at compile time, not running programs?

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

And I want the same error to occur if my CSV parser
tries to convert '123 456' into a single number.
I don't want it to assume the number is '123456'.

 

[Ben Finney]

IDLE 1.2c1['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.

 

[Ben Finney]

On Jul 25, 8:54?pm, Steven D'Aprano
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.