T
TimeHorse
I would like to gauge interest in the following proposal:
Problem:
Assignment statements cannot be used as expressions.
Performing a list of mutually exclusive checks that require data
processing can cause excessive tabification. For example, consider
the following python snipet...
temp = my_re1.match(exp)
if temp:
# do something with temp
else:
temp = my_re2.match(exp)
if temp:
# do something with temp
else:
temp = my_re3.match(exp)
if temp:
# do something with temp
else:
temp = my_re4.match(exp)
# etc.
Even with 2-space tabification, after about 20 matches, the
indentation will take up half an 80-column terminal screen.
Details:
Python distinguishes between an assignment statement and an equality
expression. This is to force disambiguation of assignment and
comparison so that a statement like:
if x = 3:
Will raise an expression rather than allowing the programmer to
accidentally overwrite x. Likewise,
x == 3
Will either return True, False or raise a NameError exception, which
can alert the author of any potential coding mistakes since if x = 3
(assignment) was meant, assignment being a statement returns nothing
(though it may raise an exception depending on the underlying
assignment function called).
Because this forced disambiguation is a guiding virtue of the python
language, it would NOT be wise to change these semantics of the
language.
Proposal:
Add a new assignment-expression operator to disambiguate it completely
from existing operators.
Although any number of glyph could be used for such a new operator, I
here propose using pascal/gnu make-like assignment. Specifically,
let:
x = 3
Be a statement that returns nothing;
let:
x == 3
Be an expression that, when x is a valid, in-scope name, returns True
or False;
let:
x := 3
Be an expression that first assigned the value (3) to x, then returns
x.
Thus...
if x = 3:
# Rais exception
pass
if x == 3:
# Execute IFF x has a value equivalent to 3
pass
if x := 3:
# Executes based on value of x after assignment;
# since x will be 3 and non-zero and thus represents true, always
executed
pass
Additional:
Since python allows in-place operator assignment, (e.g. +=, *=, etc.),
allow for these forms again by prefixing each diglyph with a colon
), forming a triglyph.
E.g.
if x :+= 3:
# Executes IFF, after adding 3 to x, x represents a non-zero number.
pass
Also note, that although the colon operator is used to denote the
beginning of a programme block, it should be easily distinguished from
the usage of : to denote a diglyph or triglyph assignment expression
as well as the trinary conditional expression. This is because
firstly, the statement(s) following a colon) in existing python
should never begin with an assignment operator. I.e.,
if x: = y
is currently not valid python. Any attempt at interpreting the
meaning of such an expression in the current implementation of python
is likely to fail. Secondly, the diglyph and triglyph expressions do
not contain spaces, further disambiguating them from existing python.
Alternative proposals for dyglyph and triglyph representations for
assignment expressions are welcome.
Implementation details:
When the python interpreter parser encounters a diglyph or triglyph
beginning with a colon) and ending with an equals sign (=), perform
the assignment specified by glyph[1:] and then return the value of the
variable(s) on the left-hand side of the expression. The assignment
function called would be based on standard python lookup rules for the
corresponding glyph[1:] operation (the glyph without the leading
colon).
Opposition:
Adding any new operator to python could be considered code bloat.
Using a colon in this way could still be ambiguous.
Adding the ability to read triglyph operators in the python
interpreter parser would require too big a code revision.
Usage is too obscure.
Using an assignment expression would lead to multiple conceptual
instructions for a single python statement (e.g. first an assignment,
then an if based on the assignment would mean two operations for a
single if statement.)
Comments:
[Please comment]
Jeffrey.
Problem:
Assignment statements cannot be used as expressions.
Performing a list of mutually exclusive checks that require data
processing can cause excessive tabification. For example, consider
the following python snipet...
temp = my_re1.match(exp)
if temp:
# do something with temp
else:
temp = my_re2.match(exp)
if temp:
# do something with temp
else:
temp = my_re3.match(exp)
if temp:
# do something with temp
else:
temp = my_re4.match(exp)
# etc.
Even with 2-space tabification, after about 20 matches, the
indentation will take up half an 80-column terminal screen.
Details:
Python distinguishes between an assignment statement and an equality
expression. This is to force disambiguation of assignment and
comparison so that a statement like:
if x = 3:
Will raise an expression rather than allowing the programmer to
accidentally overwrite x. Likewise,
x == 3
Will either return True, False or raise a NameError exception, which
can alert the author of any potential coding mistakes since if x = 3
(assignment) was meant, assignment being a statement returns nothing
(though it may raise an exception depending on the underlying
assignment function called).
Because this forced disambiguation is a guiding virtue of the python
language, it would NOT be wise to change these semantics of the
language.
Proposal:
Add a new assignment-expression operator to disambiguate it completely
from existing operators.
Although any number of glyph could be used for such a new operator, I
here propose using pascal/gnu make-like assignment. Specifically,
let:
x = 3
Be a statement that returns nothing;
let:
x == 3
Be an expression that, when x is a valid, in-scope name, returns True
or False;
let:
x := 3
Be an expression that first assigned the value (3) to x, then returns
x.
Thus...
if x = 3:
# Rais exception
pass
if x == 3:
# Execute IFF x has a value equivalent to 3
pass
if x := 3:
# Executes based on value of x after assignment;
# since x will be 3 and non-zero and thus represents true, always
executed
pass
Additional:
Since python allows in-place operator assignment, (e.g. +=, *=, etc.),
allow for these forms again by prefixing each diglyph with a colon
), forming a triglyph.E.g.
if x :+= 3:
# Executes IFF, after adding 3 to x, x represents a non-zero number.
pass
Also note, that although the colon operator is used to denote the
beginning of a programme block, it should be easily distinguished from
the usage of : to denote a diglyph or triglyph assignment expression
as well as the trinary conditional expression. This is because
firstly, the statement(s) following a colon
) in existing pythonshould never begin with an assignment operator. I.e.,
if x: = y
is currently not valid python. Any attempt at interpreting the
meaning of such an expression in the current implementation of python
is likely to fail. Secondly, the diglyph and triglyph expressions do
not contain spaces, further disambiguating them from existing python.
Alternative proposals for dyglyph and triglyph representations for
assignment expressions are welcome.
Implementation details:
When the python interpreter parser encounters a diglyph or triglyph
beginning with a colon
) and ending with an equals sign (=), performthe assignment specified by glyph[1:] and then return the value of the
variable(s) on the left-hand side of the expression. The assignment
function called would be based on standard python lookup rules for the
corresponding glyph[1:] operation (the glyph without the leading
colon).
Opposition:
Adding any new operator to python could be considered code bloat.
Using a colon in this way could still be ambiguous.
Adding the ability to read triglyph operators in the python
interpreter parser would require too big a code revision.
Usage is too obscure.
Using an assignment expression would lead to multiple conceptual
instructions for a single python statement (e.g. first an assignment,
then an if based on the assignment would mean two operations for a
single if statement.)
Comments:
[Please comment]
Jeffrey.