On Tue, Oct 18, 2016, at 02:10, Nick Coghlan wrote:
Hi, I contributed the current list comprehension implementation (when refactoring it for Python 3 to avoid leaking the iteration variable, as requested in PEP 3100 ), and "comprehensions are syntactic sugar for a series of nested for and if statements" is precisely my understanding of how they work, and what they mean.
But it's simply not true. It has never been true and it will never be true. Something is not "syntactic sugar" if it doesn't compile to the exact same sequence of operations as the thing it is supposedly syntactic sugar for. It's a useful teaching tool (though you've eventually got to teach the differences), but claiming that it's "syntactic sugar" - and "non-negotiably" so, at that - implies that it is a literal transformation.
I said "limited" in reference to the specific claim - which was not yours - that since "yield a, b" yields a tuple, "yield *x" [and therefore (*x for...)] ought to also yield a tuple, and I stand by it. It's the same kind of simplistic understanding that should lead one to believe that not only the loop variable but also the "result" temporary ought to exist after the comprehension is executed.
I was being entirely serious in saying that this is like objecting to normal unpacking on the grounds that an ordinary list display should be considered syntactic sugar for an unrolled sequence of append calls. In both cases, the equivalence is not exact, and there should be room to at least discuss things that would merely require an additional rule to be added (or changed, technically making it "result += [...]" would cover both cases) to the transformation - a transformation which already results in three different statements depending on whether it is a list comprehension, a set comprehension, or a generator expression (and a fourth if you count dict comprehensions, though that's a different syntax too) - rather than simply declaring them "not negotiable".
Declaring this "not negotiable" was an incredibly hostile dismissal of everyone else's position. Especially when what's being proposed wouldn't invalidate the concept, it would just change the exact details of what the transformation is. Which is more than can be said for not leaking the variable.