But the proposal has explicit syntax that point the reader to the fact that
the invariant doesn't hold. Same as other unpacking occurences:
The invariant does not hold. And that's explicit.
בתאריך יום ב׳, 17 באוק' 2016, 21:16, מאת 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
> 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
> 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
> Code of Conduct: http://python.org/psf/codeofconduct/
Python-ideas mailing list
Code of Conduct: http://python.org/psf/codeofconduct/