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

[Brendan Barnwell]

On 2016-10-17 10:32, Steven D'Aprano wrote:
> In a list comprehension, we expect the invariant that the number of
> items produced will equal the number of loops performed. (Less if there
> are any "if" clauses.) There is one virtual append per loop. You cannot
> get the behaviour you want without breaking that invariant: either the
> append has to be replaced by extend, or you have so insert an extra loop
> into your mental picture of comprehensions.
>
> Yet again, for emphasis: I understand that you don't believe that
> invariant is important, or at least you are willing to change it. But
> drop the pretense that this is an obvious extension to the well-
> established behaviour of list comprehensions and sequence unpacking.

	It seems to me that this difference is fundamental.  The entire point 
of this type of generalization is to break that invariant and allow the 
number of elements in the result list to vary independently of the 
number of iterations in the comprehension.

	It seems that a lot of this thread is talking at cross purposes, 
because the specifics of the syntax don't matter if you insist on that 
invariant.  For instance, there's been a lot of discussion about whether 
this use of * is or isn't parallel to argument unpacking or assignment 
unpacking, or whether it's "intuitive" to some people or all people. 
But none of that matters if you insist on this invariant.  If you insist 
on this invariant, no syntax will be acceptable; what is at issue is the 
semantics of enlarging the resulting list by more than one element.

	Now, personally, I don't insist on that invariant.  I would certainly 
like to be able to do more general things in a list comprehension, and 
many times I have been irritated by the fact that the one-item-per-loop 
invariant exists.  I'm not sure whether I'm in favor of this particular 
syntax, but I'd like to be able to do the kind of things it allows.  But 
doing them inherently requires breaking the invariant you describe.

-- 
Brendan Barnwell
"Do not follow where the path may lead.  Go, instead, where there is no 
path, and leave a trail."
    --author unknown