[Python-ideas] Fwd: Fwd: Fwd: unpacking generalisations for list comprehension

[Nick Coghlan]

On 16 October 2016 at 14:44, Greg Ewing <greg.ewing at canterbury.ac.nz> wrote:
> Steven D'Aprano wrote:
>
>> This thread is a huge, multi-day proof that people do not agree that this
>> is a "reasonable" interpretation.
>
> So far I've seen one very vocal person who disgrees, and
> maybe one other who isn't sure.

"Language design by whoever shouts the loudest and the longest" is a
terrible idea, and always has been. It's why "Has Guido already muted
the thread?" is a useful metric for whether or not people are wasting
their time in an unproductive argument (I don't know if he's muted
this particular thread by now, but I'd be genuinely surprised if he
hasn't)

Remember that what we're arguing about is that existing instances of:

  [x for subiterable in iterable for x in subiterable]

or:

   list(itertools.chain.from_iterable(iterable))

would be easier to read and maintain if they were instead written as:

  [*subiter for subiter in iterable]

That's the bar people have to reach - if we're going to add a 3rd
spelling for something that already has two spellings, then a
compelling argument needs to be presented that the new spelling is
*always* preferable to the existing ones, *not* merely "some people
already agree that this 3rd spelling should mean the same thing as the
existing spellings".

The only proposal in this thread that has come close to reaching that
bar is David Mertz's proposal to reify single level flattening as a
flatten() builtin:

    [x for x in flatten(iterable)]

or, equivalently:

    list(flatten(iterable))

Then the only thing that folks need to learn is that Python's builtin
"flatten()" is a *non-recursive* operation that consistently flattens
one layer of iterables with no special casing (not even of strings or
bytes-like objects).


> Many people do, and it's a perfectly valid way to think
> about them. They're meant to admit a declarative reading;
> that's the reason they exist in the first place.
>
> The expansion in terms of for-loops and appends is just
> *one* way to describe the current semantics. It's not
> written on stone tablets brought down from a mountain.
> Any other way of thinking about it that gives the same
> result is equally valid.

This is why I brought up mathematical set builder notation early in
the thread, and requested that people present prior art for this
proposal from that domain. It's the inspiration for comprehensions, so
if a proposal to change comprehensions:

- can't be readily explained in terms of their syntactic sugar for
Python statements
- can't be readily explained in terms of mathematical set builder notation

then it's on incredibly shaky ground.

>> magically adds an second invisible for-loop to your list comps:
>
> You might as well say that the existing * in a list
> display magically inserts a for-loop into it. You can
> think of it that way if you want, but you don't have
> to.
>
>> it is intentionally
>> prohibited because it doesn't make sense in the context of list comps.
>
> I don't know why it's currently prohibited. You would
> have to ask whoever put that code in, otherwise you're
> just guessing about the motivation.

No need to guess, PEP 448 says why they're prohibited:
https://www.python.org/dev/peps/pep-0448/#variations

"This was met with a mix of strong concerns about readability and mild
support. "

Repeatedly saying "All of you people who find it unreadable are wrong,
it's perfectly readable to *me*" does nothing except exacerbate the
readability concerns, as folks who find it intuitive will use it over
the more explicit existing alternatives, creating exactly the
readability and maintainability problem we're worried about. Cryptic
syntactic abbreviations are sometimes worthwhile when they're
summarising something that can't otherwise be expressed easily in the
form of an expression, but that isn't the case here - the existing
alternatives are already expressions, and one of them already doesn't
require any imports.

Regards,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia