[Paul Rubin] >> You snipped out the examples I gave, like [x*x for x in range(5)] >> leaving unnecessary residue in the name space. Was it not >> obvious from the beginning that that was a kludge? If it was >> obviously a kludge, was it not obvious that there would be >> reason to want to fix it someday? I'm saying that if some new >> feature is going to need a fix later, it's better to fix it before >> releasing it in the first place.
[Steve Holden] > Well no, I certainly have never thought the name droppings from > list comprehensions to be anything other than a wart. > > But my parting shot was simply to point out that you don't > always know where you're going until you're at least part of the > way there. Until the feature exists, how do you know it needs > fixing? > > The fact that a bright bunch like the Python developers didn't > realize that it would be sensible to have a local scope for the list > comprehension variable is a perfect demonstration of that point. Well, language design issues aren't really that mysterious. It was, for example, _always_ obvious that Scheme-heads would complain about the way listcomps got implemented (wrt the scope of the iteration vrbl). But at that time, Python didn't have lexical scoping, and it wasn't clear that it ever would. So what's the bigger wart? Making listcomps exactly equivalent to an easily-explained Python for-loop nest, or introducing a notion of lexical scope unique to listcomps, hard to explain in terms of the way the rest of the language worked? The former was thought to be the lesser evil at the time, and for truly obvious reasons. Except, perhaps, to those looking at Python as if it were a flawed approximation to some other language -- as Lispers and Schemers are notoriously prone to do, even wrt each others' favorite dialects. At the time, the right decision was made. -- http://mail.python.org/mailman/listinfo/python-list
