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
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
