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
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4