Proposed new syntax

[Ben Finney]

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

> On Mon, 14 Aug 2017 07:59 pm, Ben Finney wrote:
> > You began by asking what people would expect syntax to mean.
> > 
> > Then you expressed surprise that anyone would think a comprehension
> > would be interpreted by the reader as a single operation.
>
> Yes, and I stand by that.

In the face of the designer saying that's how the feature was intended
to be interpreted by a reader, you *remain* surprised anyone could think
that?

I find it hard to believe you are denying facts to this extent.

> Python list comprehensions are explicitly documented as being equivalent to a
> loop, the syntax chosen uses the same keyword as a loop, the implementation
> uses a loop, and when read as pseudo-code they explicitly claim to be
> a loop.
> So on what basis would anyone conclude that they aren't loops?

Python's list comprehensions are explicitly drawn from set theory, the
syntax chosen uses the same words mathematicians use for set operations.

I'm not saying what you wrote above is incorrect. But it is *also* true
what I wrote.

Since this is a thread you began by asking how people would interpret
some syntax, *both of these are relevant*, even if incompatible.

> > The designer of that feature expressed that yes, the intention was
> > that it be interpreted as a single conceptual operation, not a
> > looping sequence of operations.
>
> What matters is how comprehensions actually *are*, not what Greg
> intended.

When it comes to the matter you actually raised – how a person reading
the syntax will interpret it – implementation is barely at play.

What matters much more is the connotations and baggage of language and
syntax not in the Python implementation, but *in the reader's mind*.

That's why it is an ongoing non sequitur that, when people honestly say
what leads them to interpret the syntax a particular way, you then point
to the Python implementation.

> Greg's intention simply doesn't matter. List comprehensions in Python
> are as they are documented and implemented, not as he intended them to
> be.

As a statement about what Python *will actually* do, of course that's
true.

But it's not what you asked, and 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.

> People are free to interpret Python features any way they like, but we
> don't have to treat them seriously if their interpretation doesn't
> match the documented semantics of the feature.

Then why ask people's interpretations at the start of this thread?

The Python executable can be freely designed to interpret syntax any way
its designers choose. But those are *choices*, and we can expect the
designers to inform those choices from the existing connotations and
baggage of language and syntax from outside and prior to Python — and
even from outside any programming languages.

If the design of Python's semantics sufficiently violates an established
interpretation of language or syntax, we don't have to treat it
seriously and can rightly call it a design bug.

-- 
 \     “Having sex with Rachel is like going to a concert. She yells a |
  `\      lot, and throws frisbees around the room; and when she wants |
_o__)                        more, she lights a match.” —Steven Wright |
Ben Finney