Proposed new syntax

[Steve D'Aprano]

On Tue, 15 Aug 2017 09:10 am, Ben Finney wrote:

> 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?

Yes. What the designer intended matters not a whit, what matters is what was
actually designed. Whatever Greg intended, it didn't even last long enough to
make it into the PEP, let alone the language.

As I asked Greg earlier:

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?

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.

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.

The same doesn't apply to map(), at least in Python 2. I think it is completely
reasonable for somebody to imagine that map() operated as a single operation.
They would be wrong, of course, but not egregiously wrong. There's no PEP to
contradict it, the documentation is consistent with map being an atomic
operation:

https://docs.python.org/2/library/functions.html#map

the name is the same as the functional "map", which in purely functional
languages is intended to be read as a mathematical operation which takes a
function and a list and returns a new list.

There may be subtle aspects of map in Python 2 which reveal that it is not
actually a single conceptual operation (side-effects, of course, and the fact
that you can interrupt it with Ctrl-C) but they are subtle and it is reasonable
for somebody to miss them, or to argue that they are mere accidents of
implementation.

But comprehensions? You can't even write a comprehension without being reminded
that they are designed as an expression form of for-loops! That's why I was,
and remain, perplexed that you could ignore the documentation and the behaviour
of comprehensions and believe something so egregiously wrong about them.


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

I don't know what facts you think I'm ignoring.


>> 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.

No they don't. Set builder notation doesn't use words at all, it uses symbols:

{n+1 | n ∈ {1, 2, 3}}

which if we were to translate into words would be:

"the set of n plus one, such that n is an element of the set 1, 2 and 3".

That's not even close to the same words as Python's comprehensions.

Aside: The interesting thing about sets in mathematics is that they're
unordered, unless it is useful for them to be thought of as ordered, in which
case they're taken as ordered. E.g. when talking about arithmetic or geometric
sequences, the unordered set of integers is taken as an ordered set, with no
change in notation or language.



[...]
>> 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.

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?"

is best answered by predicting that Python will do something that you know it
actually won't do. I can't believe you mean it that way, so I'm more perplexed
than ever.


>> 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?

Because I wanted to know what their interpretations are, and not being
omniscient the only way to do so is to ask.

At no point did I promise that I wouldn't question their answers, if they made
no sense to me.


> 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.

Of course you can. There are millions of programmers who claim that:

- significant indentation is a design bug;

- dynamic typing is a design bug;

- everything about Unicode is a design bug, and we should all just use ASCII;

- exceptions are a design bug;

- early evaluation of function default arguments is a design bug;

- late evaluation of function default arguments is a design bug;

to mention just a few.


But we really haven't established that Python's comprehension semantics violates
any widely established programming language semantics. I may take that to
another thread :-)



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