Proposed new syntax

[Steve D'Aprano]

On Mon, 14 Aug 2017 07:59 pm, Ben Finney wrote:

> Steven D'Aprano <steve+comp.lang.python at pearwood.info> writes:
> 
>> On Sun, 13 Aug 2017 21:06:08 -0700, Rustom Mody wrote:
>>
>> > Here's a bunch of different ways in which a mapping comprehension
>> > could be implemented:
>>
>> Not in Python they couldn't be
> 
> 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.

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? That's a genuine
question, not a rhetorical question. I meant it when I said I could understand
people imagining that the Python 2 versions of map() or filter() could be
implemented as something other than a straightforward sequential loop, but I'm
puzzled how anyone could imagine that of list comprehensions and generator
expressions.

The author of the PEP which introduced list comps to the language, Barry Warsaw,
wrote:

"They [comprehensions] would nest in the same way for loops and if statements
nest now."

Guido added to the PEP:

"The form [... for x... for y...] nests, with the last index varying fastest,
just like nested for loops."

https://www.python.org/dev/peps/pep-0202/


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

- The PEP states that comprehensions are equivalent to loops; if Greg 
  intended different, he should have written the PEP to say so.

- The syntax chosen is that of a procedural for-loop, not a declarative 
  "select where" statement.

- The semantics of the comprehension is explicitly documented as equivalent
  to nested for-loops.

- Guido blessed both the syntax and the semantics.

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.


> Your latest counter has been that Python means something special, beyond
> what the feature's designer intended, and it's implemented as a looping
> sequence of operations.

The implementation is the least of my arguments, since it could change to a
while loop without affecting the semantics of comprehensions and generator
expressions. Or a series of unrolled loops, or to use goto or comefrom for that
matter.

The critical point is that the actual semantics, as stated in the PEP and the
documentation is a for-loop, and the syntax chosen is self-documenting as a
for-loop.

Greg may have intended that comprehensions being equivalent to nested for-loops
be taken as a mere analogy, but that's not the path Python has taken. It is not
an analogy, but a language promise that all comprehensions will be semantically
equivalent to for-loops.



[...]
> You were apparently, at the start of this thread, honestly seeking to
> know how people interpret the syntax.

Indeed.

About half the people who responded interpreted it with the same way semantics
as the Clojure list comprehensions which inspired it. Some people interpreted
it as an infinite loop. You claimed that it was impossible to understand; one
person claimed that it would cause unending confusion; one person saw no
difference between "while" and "if", and one person seemed to believe that even
the existing "if" clause should be a syntax error.



> At what point will you accept the feedback: 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.

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.

I might honestly, strongly believe that

    del x

causes the object referenced by x to be garbage collected. I can say that's how
it works in other languages, I can say that's what the designer intended all
those many years ago, I can even insist that there is no other logical way for
del to operate and any other behaviour would be inconceivable and a source of
unending confusion.

Nevertheless, that isn't how del operates, it isn't how it is documented, and my
opinion is simply wrong. If I gave a code review where I insisted that:

    x = y = some_object()
    del x
    print(y)

is unsafe because the object has been garbage collected, you would be right to
ignore that feedback. Not because you don't like my review, but because it is
based on a misconception and is simply factually wrong.



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