seeking deeper (language theory) reason behind Python design choice

[bartc]

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