Proposed new syntax

[Steve D'Aprano]

On Tue, 15 Aug 2017 08:26 am, Gregory Ewing wrote:

> Ben Finney wrote:
>> That the comprehension
>> syntax *does not* necessarily connote a procedural loop, but instead can
>> quite reasonably be interpreted as its designer intended, a single
>> conceptual operation.
> 
> To put it another way: Consider that a comprehension is an
> expression, and I think most people would agree that relying
> on order of evaluation in an expression is a very bad idea,
> since it hurts readability and is prone to subtle bugs.

So you've stopped arguing that list comprehensions don't have a defined order
of evaluation, and are now arguing that code which relies on that order of
evaluation is hard to reason about? I suppose that's progress :-)

I take issue with your statement that relying on order of evaluation is always 
"a very bad idea". Order of evaluation in Python is well-defined, and we
frequently rely on it. There is nothing wrong with writing code like:

    x = y + 1/z

    x is not None and x > 1

    a, b = b, a

    while x in foo or x not in bar

and similar. And especially now that print is a regular function instead of a
statement, it is incredibly useful to stick a print or two in the middle of an
expression for debugging. You can't use that trick everywhere, but it is
especially useful in generator expressions as a way of seeing when its called
and yields a value:

    (print('generator', x) or expression for x in something)

for example.

But really, the argument that you seem to be making:

    # paraphrase, not an actual quote
    "Comprehensions might actually have well-defined semantics in terms
    of for-loops, just as they are documented to have, but we should
    pretend that they don't because some really complicated expressions
    with side-effects can be confusing or buggy."

seems pretty dubious to me.


As they say, "A man's got to know his limitations." If you program code that is
as complicated as you can understand, you won't be clever enough to debug it
when it goes wrong. That applies whether we're talking about order of
evaluation, basic arithmetic, threads, async programming, functional idioms,
levels of abstraction or spaghetti code. That makes a good argument for writing
conservative code that is the simplest thing that will work (for some
definition of "work").

It's not an argument for treating the semantics of code as different from what
those semantics actually are.



-- 
Steve
“Cheer up,” they said, “things could be worse.” So I cheered up, and sure
enough, things got worse.