But the proposal has explicit syntax that point the reader to the fact that the invariant doesn't hold. Same as other unpacking occurences:
[x, *y] The invariant does not hold. And that's explicit. Elazar בתאריך יום ב׳, 17 באוק' 2016, 21:16, מאת Brendan Barnwell < brenb...@brenbarn.net>: > 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/ >
_______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
