On 14 October 2016 at 07:54, Greg Ewing <greg.ew...@canterbury.ac.nz> wrote:
>> 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-sets-and-dictionaries
> 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

Python-ideas mailing list
Code of Conduct: http://python.org/psf/codeofconduct/

Reply via email to