Proposed new syntax

[Ben Finney]

Steve D'Aprano <steve+python at pearwood.info> writes:

> If he wanted declarative semantics, why didn't he argue for
> declarative syntax like "select...where", instead of choosing
> procedural syntax which matches the actual procedural semantics given?

The syntax “f(foo) for foo in bar if baz(foo)” is nicely declarative.

> In order to think of list comps as declarative, you have to:
>
> - ignore the PEP;
> - ignore the documentation;
> - ignore the actual behaviour;
> - ignore the syntax.
>
> That's a lot of reality to ignore.

Python's list comprehensions behave as I expect that syntax to behave,
from the declarative, single-conceptual-operation expression model. I'm
not ignoring the behaviour or syntax.

The PEP and documentation, I will admit to ignoring (or at least have
forgotten since I first read them, now that I've got Python's actual
behaviour working with an widely known mental model).

The Python behaviour and mental model fit fine together, so I just keep
programming on that basis.

> That's why I was surprised at your attitude that list comps could
> reasonably be interpreted as a single operation. To do so requires
> ignoring everything we know about list comprehensions in Python.

I hope that clarifies. Everything about how Python's list comprehension
behaves, at a Python language level, supports the mental model of a list
comprehension as a single conceptual operation.

Does Python's behaviour *also* support the mental model of “it's like a
for loop”? Yes. Python supports multiple mental models, that should be
no surprise.

> But comprehensions? You can't even write a comprehension without being
> reminded that they are designed as an expression form of for-loops!

I'm reminded of a set operation. It works just fine that way.

> > […] your bafflement at getting answers not to the question you
> > didn't ask, but instead to the question you did ask, is becoming
> > quite strange.
>
> I don't understand this. You seem to be implying that the answer to
> the question:
>
> "What do you think Python will do if you execute a list
> comprehension?"

You didn't ask about what it *will do*, you asked about syntax that
Python does not yet support (a ‘while’ keyword in a list comprehension).

The correct answer to “What do you think Python will do if you execute
an expression with an invalid keyword in it?” is “Python will raise a
SyntaxError”.

Indeed, you got just such an answer, and it was an answer to the wrong
question as you rightly pointed out at the time.

Instead, you asked the much more interesting question: With the ‘while’
keyword in the expression, what do you think Python *would do* if it
supported such an expression?

So you're asking us not what Python *will in fact* do with that
syntax (today, it will raise an error). You're asking us what *the
proposed syntax would mean* if Python supported it.

> is best answered by predicting that Python will do something that you
> know it actually won't do.

You're asking something very similar. Because this is *proposed* syntax,
presently not valid Python, you're asking us to speculate about some
putative future Python, based on our mental models of Python semantics.

> But we really haven't established that Python's comprehension
> semantics violates any widely established programming language
> semantics.

Python's comprehension semantics do not violate those widely established
semantics, so you can stop waiting for anyone to try establishing that.

I'm responding to the proposal by pointing out that, unlike today's
Python, the proposed behaviour would violate those semantics.

-- 
 \        “It is seldom that liberty of any kind is lost all at once.” |
  `\                                                       —David Hume |
_o__)                                                                  |
Ben Finney