Zen of Python
ajsiegel at optonline.com
Sat Jan 22 09:36:55 EST 2005
On 21 Jan 2005 20:32:46 -0800, Paul Rubin
>Of course in that case, since the absence of lexical scope was a wart
>in its own right, fixing it had to have been on the radar. So turning
>the persistent listcomp loop var into a documented feature, instead of
>describing it in the docs as a wart that shouldn't be relied on,
>wasn't such a hot idea. Adding lexical scope and listcomps at the
>same time might have also been a good way to solve the issue.
Most of us go about our business without a fine grained reading of the
documentation. I don't think I would be unusual in having learned
about listcomp lakkage by tracing a hard to fathom bug to its source.
I can't say I understood at that point that for loops *do* leak. But
apparently *did* understand intutively that I shouldn't rely on it not
doing so. because I chose my local variable names in a way that I
couldn't get hurt in any case My intution apparently felt safe in
doing otherwise in the vicinity of a list comp, which is how I got
burnt. The fact is there was carelessness in the code that surrounded
the bug. But it was carelessness of the kind that would, in the
absence of list com leakage, have led to an easy to recgnize error
message and a quick fix.
Nobody likes to hear coulda, shoulda s for done deals.
But the issue is an a basic one, in some sense, it seems to me.
The question around decorators did not seem too dissimilar. There was
those would thought that a better solution to the problem being
addressed would most likely naturally present itself further down the
road as Python evolved. And that inaction at this time was the best
Or that a solution should be found that addressed that issue,
toigether with related issues, in a way that was less of a "best to to
done under the cirucmstances as of now", before a trigger was pulled.
woulda, coulda shoulda.
More information about the Python-list