On 08/16/2011 10:31 AM, Philip Semanchuk wrote:
On Aug 16, 2011, at 11:12 AM, Chris Angelico wrote:
There are several types of shadowing:
1) Deliberate shadowing because you want to change the behavior of the
name. Extremely rare.
2) Shadowing simply by using the name of an unusual builtin (like
'file') in a context where you never use it. Very common.
3) Unintentional shadowing where you create a variable, but then
intend to use the builtin. This is the only one that's a
problem.
Yes, but before you get to #3 you have to go through #2. The
way I see it, #2 is setting a trap, #3 is actually stepping
in it. I don't want to do either. Neither do I like working
with code that has set trap #2 for me.
Chris succinctly described the times I've done shadowing.
Fortunately, the shadowing done in #3 (which you appropriately
describe as being a superset of #2) is fairly remedied with most
editors...since it usually occurs when you have "oh, I
accidentally shadowed builtin X", so you just do a global
search-and-replace for all those places you shadowed X and rename
it to something like "my_X" and proceed to use X as the builtin.
The bigger issue I have is module shadowing which is trickier to
catch and produces weird symptoms (i.e. cryptic errors). The
most common one I see is creating a local module called
"email.py" and then having issues when trying to use
standard-library email calls which find your local email.py
before they find the email.py file in the standard library. I
actually wrote a tool to scan for duplicate modules in
$PYTHONPATH (pretty dumb tool, could easily have broken on things
like zipfile imports, DLLs, etc), but it made diagnosing the
issue easier.
-tkc
--
http://mail.python.org/mailman/listinfo/python-list
