seeking deeper (language theory) reason behind Python design choice
bartc
bc at freeuk.com
Wed May 9 17:48:42 EDT 2018
On 09/05/2018 06:44, Steven D'Aprano wrote:
> On Tue, 08 May 2018 22:48:52 -0500, Python wrote:
>
> But by the time 1.4 came around, Guido had settled on a clean separation
> between statements and expressions as part of Python's design.
>
> That separation has gradually weakened over the years,
Presumably it's non-existent now, as it seems you can type any
expression as a statement in its own right:
"stmt"
a + b*c
p == 0
with the addition
> of the ternary if operator
If you mean that this is a kind of statement that can be incorporated
into an expression, then just class it as an operator not a statement.
(They are different in any case, for example statement-if doesn't return
a value.)
> and comprehensions,
And that one, although it's a more complex example.
> It might simply be that Guido (like many people) considered assignment to
> fundamentally be an imperative command, not an expression.
You design a language, you get to choose how it works.
(I allow assignments in expressions in my languages, but the two are
different constructs: statement-assignment returns no value;
expression-assignment does, although both use ":=" syntax for the
assignment operator.
That's OK ":=" doesn't really get mixed up with "=" for equality as "="
and "==" would do. So one answer would be to use something other than
"=" for assignments within expressions.
I don't however allow augmented assignments in expressions, as it's not
that useful, and it would be too much (and I could never get the
precedences right). But normal assignment is handy.)
--
bartc
More information about the Python-list
mailing list