On 14 October 2016 at 07:54, Greg Ewing
I think it's probably time for someone to describe the precise syntax (as BNF, like the syntax in the Python docs at https://docs.python.org/3.6/reference/expressions.html#displays-for-lists-se...
Replace
comprehension ::= expression comp_for
with
comprehension ::= (expression | "*" expression) comp_for
and semantics (as an explanation of how to rewrite any syntactically valid display as a loop).
The expansion of the "*" case is the same as currently except that 'append' is replaced by 'extend' in a list comprehension, 'yield' is replaced by 'yield from' in a generator comprehension.
Thanks. That does indeed clarify. Part of my confusion was that I'm sure I'd seen someone give an example along the lines of [(x, *y, z) for ...] which *doesn't* conform to the above syntax. OTOH, it is currently valid syntax, just not an example of *this* proposal (that's part of why all this got very confusing). So now I understand what's being proposed, which is good. I don't (personally) find it very intuitive, although I'm completely capable of using the rules given to establish what it means. In practical terms, I'd be unlikely to use or recommend it - not because of anything specific about the proposal, just because it's "confusing". I would say the same about [(x, *y, z) for ...]. IMO, combining unpacking and list (or other types of) comprehensions leads to obfuscated code. Each feature is fine in isolation, but over-enthusiastic use of the ability to combine them harms readability. So I'm now -0 on this proposal. There's nothing *wrong* with it, and I now see how it can be justified as a generalisation of current rules. But I can't think of any real-world case where using the proposed syntax would measurably improve code maintainability or comprehensibility. Paul