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
_______________________________________________
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/