comprehensions was Re: Switch statements again

[Tim Peters]

[Tim]
> At the time, lexical nesting didn't yet exist in Python either.
> The case for "magically local" bindings has gotten stronger since
> lexical nesting was added, but now we've got a backwards compatibility
> burden too.

[Ville Vainio]
> Backwards compatibility would be less of a burden if it was flagged as
> "possibly unsupported in the future" in the documentation.

That wouldn't help, and it's not undefined now anyway.  Changing defined
behavior in incompatible ways requires a future statement and (at least) a
full dot-release transition period.

> At least it would do a bit to alleviate the embarrassment felt when
> explaining the feature to colleagues, 5 minutes after touting how well
> designed python is ;-).

I don't think the case is compelling even with lexical nesting, just
stronger than it was.  There are very few constructs in Python that
introduce a code block, that set hasn't changed, and neither has that scopes
are associated only with code blocks (see the "Code blocks, execution
frames, and namespaces" section of the Ref Man).  It would be a wart of a
different kind if listcomps were considered to establish a new code block,
and a wart of a third kind if listcomps weren't considered to introduce a
new code block but were unique in introducing a new scope anyway.  "Good
design" has to balance lots of things, and protecting a programmer against
sloppy reuse of variable names is only one of them.

I've never found that the the binding done by listcomps is useful after the
listcomp has finished, but then I've never been burned by it either.  That
it *can* burn the careless is a wart too, of course.  OTOH, the ability to
explain listcomps semantics exactly via appeal to an equivalent loop nest is
worth something too.

guido-doesn't-like-pepper-in-his-sugar-ly y'rs  - tim