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

אלעזר elazarg at gmail.com
Mon Oct 17 14:20:48 EDT 2016


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 ‏<
brenbarn at 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 at python.org
> https://mail.python.org/mailman/listinfo/python-ideas
> Code of Conduct: http://python.org/psf/codeofconduct/
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20161017/29237d64/attachment-0001.html>


More information about the Python-ideas mailing list