G
Georgy Pruss
Hi all,
I would like to propose some extentions to the language, probably
for the version 3.0. They are mainly lexical or syntactical and the
language will stay compatible with 2.X (even although it was
declared somewhere that it's not the main concern in the Python
community) but some of them are a bit more "radical." Yes, I know
that some of the proposals were discussed here before, but I don't
think it means that the language is frozen in its development
forever and that everybody's absolutely happy with what it is
today. Anyway, this is my wish list
The features I'd like to see in Python are: underscores in numbers,
binary integers, hex strings, true boolean and none constants,
enum type, optional colon, built-in regex and RE match, slices,
for-as loop, until loop, unconditional loop, one line if-else, etc.
1) Underscores in numbers. It will help to read long numbers.
E.g.
12_345_678
3.14159_26535_89793_23846
2) Binary constants. Not in great demand, just nice to have,
half an hour to implement.
E.g.
0b01110011
0b1110_0101_1100_0111
3) Hex strings. Very useful when you want to initialize long
binary data, like inline pictures.
E.g.
x'48656C6C6F 21 0D0A'
ux'0021 000D 000A'
They can be combined with other strings: 'Hello!' x'0d0a'
Now you can use hexadecimal values, but with two times
longer sequences like '\x..\x..\x..\x..', or do the translation
during run-time using '....'.decode('hex').
4) Keywords 'none', 'false', 'true'. They should be keywords,
and they should be lowercase, like all the rest keywords.
True, False and None can stay for some time as predefined
identifiers, exactly like they are now.
5) Enum type. Introduces global (module-level) constants of
number or string values. The numeric values can be assigned
automatically like in the C language. If the enum declaration
has a name, this name defines "a namespace" and it must be
specified for referring to the values.
# defines constants AXIS.X=0, AXIS.Y=1, AXIS.Z=2
enum AXIS: X, Y, Z
# defines color.red, color.green, color.blue
enum color
red = '#FF0000', green = '#00FF00', blue = '#0000FF'
# defines consts A=0, B=1, C=2, D=10, E=11, F=12
enum
A, B, C
D = 10, E
F
# the same as above
enum: A; B, C, D=10; E, F # ';' and ',' are the same here.
6) The colon is optional after for,if,try,enum etc. if it is
followed by a new line. Although it's mandatory if there are
statements on the same line. So it's like ';' -- you MUST
use it when it's needed. You CAN still use it if you like it,
like now you can put a semicolon after each statement
as well.
def abs(x)
if x < 0
return -x
else
return x
7) Built-in regex'es. It would be nice to have built-in regular
expressions. Probably, some RE functionality can be shared
with the built-in string class, like presently we can write
'x'.encode('y'). For example $str can produce a regex object
and then s==re can return true if s matches re. This would be
very good for the switch construction (see below).
E.g.
id = $ "[A-Za-z_][A-Za-z0-9_]*"
if token == id: return token
8) Slices. They can have two external forms and they are
used in three contexts: a) in [index], b) in the 'case' clause,
c) in the 'for-as' statement. The have these forms:
a:b means a <= x < b (a:b:c -- with step c)
a..b means a <= x <= b (a..b:c -- with step c)
E.g.
1:100 == 1,2,3,...,99
1..100 == 1,2,3,...,100
9) For-as loop. Actually, 'as' is chosen because it is already
used as a keyword, and it fits here quite well. Another possible
spelling can be 'from' (as somebody proposed in 1999).
for <var> as <sequence>:
<stmts>
The sequence (it also occurs in the case clause, see below)
is composed of one or more expressions or slices. This form
is very short and visual. It will permit a better optimization
comparing to the old "in range(x,y)" form.
E.g.
for n as 1:10,10:50:2,50:100:5
for item as 1..100, 201..300
The ambiguity of constructions like "for v as a():b():c()" can be
solved with additional parenthesis:
for v as a():b():c() # from a() till b() with step c(); stmts start
stmts() # on the next line
for v as (a():b()): c() # from a() till b() with step 1; do c()
for v as [a():b()]: c() # maybe this form looks better
10) Until loop -- repeat the loop body at least one time
until the condition is true.
until <postcond>
<stmts>
It's the same as:
<stmts>
while not <postcond>
<stmts>
11) Unconditional loop. Yes, I'm from the camp that
finds 'while 1' ugly. Besides, sometimes we don't need
a loop variable, just a repetition.
loop [<expr_times_to_repeat>]
<stmts>
E.g.
loop 10
print_the_form()
loop
line = file.readline()
if not line
break
process_line( line )
12) Selection statement. The sequence (it can also
occur in the for-as statement, see above) is composed
of one or more expressions or slices.
switch <expr>
case <sequence>
<stmts>
case <sequence>
<stmts>
else
<stmts>
The sequence can contain RE-patterns.
case $pattern,$pattern2 # if expr matches patterns
...
13) One line if-else.
if <cond>: <stmt>; else: <stmt>
14) Conditional expression. Yes, I'd love it.
cond ? yes : no
15) Better formatting for repr()
repr(1.1) == '1.1'
If the parser recognizes 1.1 as a certain number, I can't see
any reason why it should print it as 1.1000000000000001 for
the next parser run.
16) Depreciated/obsolete items:
-- No `...` as short form of repr();
-- No '\' for continuation lines -- you can always use parenthesis;
-- No else for while,for,try etc -- they sound very unnatural;
-- Ellipsis -- it looks like an alien in the language.
I do believe that these changes follow the spirit of the language
and help Python to become an even better language.
And I'm ready to implement them, if they pass the PEP vote
If not... I love Python anyway!
I would like to propose some extentions to the language, probably
for the version 3.0. They are mainly lexical or syntactical and the
language will stay compatible with 2.X (even although it was
declared somewhere that it's not the main concern in the Python
community) but some of them are a bit more "radical." Yes, I know
that some of the proposals were discussed here before, but I don't
think it means that the language is frozen in its development
forever and that everybody's absolutely happy with what it is
today. Anyway, this is my wish list
The features I'd like to see in Python are: underscores in numbers,
binary integers, hex strings, true boolean and none constants,
enum type, optional colon, built-in regex and RE match, slices,
for-as loop, until loop, unconditional loop, one line if-else, etc.
1) Underscores in numbers. It will help to read long numbers.
E.g.
12_345_678
3.14159_26535_89793_23846
2) Binary constants. Not in great demand, just nice to have,
half an hour to implement.
E.g.
0b01110011
0b1110_0101_1100_0111
3) Hex strings. Very useful when you want to initialize long
binary data, like inline pictures.
E.g.
x'48656C6C6F 21 0D0A'
ux'0021 000D 000A'
They can be combined with other strings: 'Hello!' x'0d0a'
Now you can use hexadecimal values, but with two times
longer sequences like '\x..\x..\x..\x..', or do the translation
during run-time using '....'.decode('hex').
4) Keywords 'none', 'false', 'true'. They should be keywords,
and they should be lowercase, like all the rest keywords.
True, False and None can stay for some time as predefined
identifiers, exactly like they are now.
5) Enum type. Introduces global (module-level) constants of
number or string values. The numeric values can be assigned
automatically like in the C language. If the enum declaration
has a name, this name defines "a namespace" and it must be
specified for referring to the values.
# defines constants AXIS.X=0, AXIS.Y=1, AXIS.Z=2
enum AXIS: X, Y, Z
# defines color.red, color.green, color.blue
enum color
red = '#FF0000', green = '#00FF00', blue = '#0000FF'
# defines consts A=0, B=1, C=2, D=10, E=11, F=12
enum
A, B, C
D = 10, E
F
# the same as above
enum: A; B, C, D=10; E, F # ';' and ',' are the same here.
6) The colon is optional after for,if,try,enum etc. if it is
followed by a new line. Although it's mandatory if there are
statements on the same line. So it's like ';' -- you MUST
use it when it's needed. You CAN still use it if you like it,
like now you can put a semicolon after each statement
as well.
def abs(x)
if x < 0
return -x
else
return x
7) Built-in regex'es. It would be nice to have built-in regular
expressions. Probably, some RE functionality can be shared
with the built-in string class, like presently we can write
'x'.encode('y'). For example $str can produce a regex object
and then s==re can return true if s matches re. This would be
very good for the switch construction (see below).
E.g.
id = $ "[A-Za-z_][A-Za-z0-9_]*"
if token == id: return token
8) Slices. They can have two external forms and they are
used in three contexts: a) in [index], b) in the 'case' clause,
c) in the 'for-as' statement. The have these forms:
a:b means a <= x < b (a:b:c -- with step c)
a..b means a <= x <= b (a..b:c -- with step c)
E.g.
1:100 == 1,2,3,...,99
1..100 == 1,2,3,...,100
9) For-as loop. Actually, 'as' is chosen because it is already
used as a keyword, and it fits here quite well. Another possible
spelling can be 'from' (as somebody proposed in 1999).
for <var> as <sequence>:
<stmts>
The sequence (it also occurs in the case clause, see below)
is composed of one or more expressions or slices. This form
is very short and visual. It will permit a better optimization
comparing to the old "in range(x,y)" form.
E.g.
for n as 1:10,10:50:2,50:100:5
for item as 1..100, 201..300
The ambiguity of constructions like "for v as a():b():c()" can be
solved with additional parenthesis:
for v as a():b():c() # from a() till b() with step c(); stmts start
stmts() # on the next line
for v as (a():b()): c() # from a() till b() with step 1; do c()
for v as [a():b()]: c() # maybe this form looks better
10) Until loop -- repeat the loop body at least one time
until the condition is true.
until <postcond>
<stmts>
It's the same as:
<stmts>
while not <postcond>
<stmts>
11) Unconditional loop. Yes, I'm from the camp that
finds 'while 1' ugly. Besides, sometimes we don't need
a loop variable, just a repetition.
loop [<expr_times_to_repeat>]
<stmts>
E.g.
loop 10
print_the_form()
loop
line = file.readline()
if not line
break
process_line( line )
12) Selection statement. The sequence (it can also
occur in the for-as statement, see above) is composed
of one or more expressions or slices.
switch <expr>
case <sequence>
<stmts>
case <sequence>
<stmts>
else
<stmts>
The sequence can contain RE-patterns.
case $pattern,$pattern2 # if expr matches patterns
...
13) One line if-else.
if <cond>: <stmt>; else: <stmt>
14) Conditional expression. Yes, I'd love it.
cond ? yes : no
15) Better formatting for repr()
repr(1.1) == '1.1'
If the parser recognizes 1.1 as a certain number, I can't see
any reason why it should print it as 1.1000000000000001 for
the next parser run.
16) Depreciated/obsolete items:
-- No `...` as short form of repr();
-- No '\' for continuation lines -- you can always use parenthesis;
-- No else for while,for,try etc -- they sound very unnatural;
-- Ellipsis -- it looks like an alien in the language.
I do believe that these changes follow the spirit of the language
and help Python to become an even better language.
And I'm ready to implement them, if they pass the PEP vote
If not... I love Python anyway!