[Python-Dev] "as" postfix notation highlights

[Ivan Pozdeev]

On 04.07.2018 10:10, Nathaniel Smith wrote:
>
> I think the most striking evidence for this is that during the
> discussion of PEP 572 we discovered that literally none of us –
> including Guido – even *know* what the order-of-evaluation is inside
> expressions.
If has stricken me that this is a highlight for the "as" syntax right here!

* Since it's a postfix, it preserves the forward reading order and is 
thus more fitting for inline syntax:

     while inv == (make_step(state, inv) as new_inv) and 
is_valid(new_inv): inv = new_inv

Makes it clear that in the first two cases, the old value of `inv' is 
used, and only after that, it's reassigned.

The prefix syntax of an assignment is instead read "from `=' on, then 
return to the start". This is okay for a standalone construct, but if 
embedded, the reading order becomes nontrivial:

     while inv == (new_inv := make_step(state, inv)) and 
is_valid(new_inv): inv = new_inv

* In the light of "Don't assign to a variable used later in the 
expression" , "as" looks completely different from assignment, which 
will deter folks from trying to do the problematic augmented assignments 
and demand expression syntax for them.

>   In fact PEP 572 now has a whole section talking about the
> oddities that have turned up here so far, and how to fix them. Which
> just goes to show that even its proponents don't actually think that
> anyone uses side-effects inside expressions, because if they did, then
> they'd consider these changes to be compatibility-breaking changes. Of
> course the whole point of PEP 572 is to encourage people to embed
> side-effects inside expressions, so I hope they've caught all the
> weird cases, because even if we can still change them now we won't be
> able to after PEP 572 is implemented.
>
> Some people make fun of Python's expression/statement dichotomy,
> because hey don't you know that everything can be an expression,
> functional languages are awesome hurhur, but I think Python's approach
> is actually very elegant. Python is unapologetically an imperative
> language, but even we dirty imperative programmers can agree with the
> functional fanatics that reasoning about side-effects and sequencing
> is hard. One-side-effect-per-line is a very elegant way to keep
> sequencing visible on the page and as easy to reason about as
> possible.
>
> Or as Dijkstra put it: "our intellectual powers are rather geared to
> master static relations and that our powers to visualize processes
> evolving in time are relatively poorly developed. For that reason we
> should do (as wise programmers aware of our limitations) our utmost to
> shorten the conceptual gap between the static program and the dynamic
> process, to make the correspondence between the program (spread out in
> text space) and the process (spread out in time) as trivial as
> possible."
>
> It's very disheartening that not only is PEP 572 apparently going to
> be accepted, but as far as I can tell neither the text nor its
> proponents have even addressed this basic issue.
>
> -n
>

-- 
Regards,
Ivan