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.