On Fri, Jun 18, 2021 at 10:15 PM Steven D'Aprano <st...@pearwood.info> wrote:
> On Fri, Jun 18, 2021 at 09:33:49PM -0700, Guido van Rossum wrote: > > > Now, this shouldn't be considered an airtight argument against [*chunk > for > > ...], but it does show that there's no straightforward explanation of its > > meaning through equivalence (like the OP seemed to think), and I think > this > > is what Serhiy was also getting at in his post. > > Indeed. I was initially confused by what Ben thought was a simple and > obvious connection between star unpacking in some other contexts and his > suggestion for comprehensions. The analogy with `[*a]` never crossed my > mind, and I don't think that we should look at this as literally the > application of sequence unpacking in a comprehension, for reasons I gave > in my earlier post. > > But having it explained to me, I think that treating this as an analogy > rather than literal unpacking works. We already give unary star and > double star a number of meanings, not all of which are related: > > > - import wildcard; > > - capture positional and keyword parameters `def func(*args, **kw)` > > - sequence and keyword unpacking in function calls; > > - sequence capture in assignment targets `head, *a, tail = items` > > - sequence unpacking in list etc displays; > > > Have I missed any? > What you seem to be (intentionally) missing is that all but the import wildcard *are* closely related, even though they are specified separately in the syntax. (Saying that they are unrelated would be like saying that the name occurring after a 'def' keyword and the function name occurring in a function call are unrelated. :-) > We could define *star comprehensions* as syntactic sugar for nested > comprehensions, to aid in flattening nested sequences and mappings. > > [*expression for name in sequence if condition] > > results in this: > > result = [] > for name in sequence: > if condition: > for tmp in expression: > result.append(tmp) > return result > > I haven't thought deeply into this, but I think that if the starred > expression is anything but a simple name, it may require parentheses? > > *name # okay > *(name.attr or []) # everything else needs parens > The grammar for the last three forms you give allows pretty much any expression, for example https://github.com/python/cpython/blob/291848195f85e23c01adb76d5a0ff9c6eb7f2614/Grammar/python.gram#L504-L506 > Alternatively, we could just do something that people have been asking > about since Python 1.5 and provide a flatten builtin or list method :-) > Probably a builtin, since in my mind I want to write flatten(a), never a.flatten(), and it would be useful for any kind of sequence of sequences (or even iterable of iterables). I think I would find flatten(a) more readable than [*chunk for chunk in a], and more discoverable: this operation is called "flatten" in other languages, so users are going to search the docs or help for that. But there could be endless debate about whether flatten( ("x", "y") ) should return a list or a tuple... -- --Guido van Rossum (python.org/~guido) *Pronouns: he/him **(why is my pronoun here?)* <http://feministing.com/2015/02/03/how-using-they-as-a-singular-pronoun-can-change-the-world/>
_______________________________________________ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/KTZLOA6DIRIJ4QHCZBVQGD36AX6JZQ5V/ Code of Conduct: http://python.org/psf/codeofconduct/
