How to guard against bugs like this one?
in [Python]
|
From: Tim Golden on 3 Feb 2010 11:33 On 03/02/2010 16:17, kj wrote: > Boy, that was dumb of me. The above apology was meant for Stephen > Hansen, not Steve Holden. I guess this is now a meta-apology... > (Sheesh.) You see? That's what I like about the Python community: people even apologise for apologising :) TJG
From: Steve Holden on 4 Feb 2010 07:04 Tim Golden wrote: > On 03/02/2010 16:17, kj wrote: >> Boy, that was dumb of me. The above apology was meant for Stephen >> Hansen, not Steve Holden. I guess this is now a meta-apology... >> (Sheesh.) > > You see? That's what I like about the Python community: > people even apologise for apologising :) > QOTW? regards Steve -- Steve Holden +1 571 484 6266 +1 800 494 3119 PyCon is coming! Atlanta, Feb 2010 http://us.pycon.org/ Holden Web LLC http://www.holdenweb.com/ UPCOMING EVENTS: http://holdenweb.eventbrite.com/
From: John Nagle on 5 Feb 2010 15:16 kj wrote: .... > > Through a *lot* of trial an error I finally discovered that the > root cause of the problem was the fact that, in the same directory > as buggy.py, there is *another* innocuous little script, totally > unrelated, whose name happens to be numbers.py. The right answer to this is to make module search return an error if two modules satisfy the search criteria. "First find" isn't a good solution. John Nagle
From: MRAB on 5 Feb 2010 15:44 Stephen Hansen wrote: > On Fri, Feb 5, 2010 at 12:16 PM, John Nagle <nagle(a)animats.com > <mailto:nagle(a)animats.com>> wrote: > > kj wrote: > > Through a *lot* of trial an error I finally discovered that the > root cause of the problem was the fact that, in the same directory > as buggy.py, there is *another* innocuous little script, totally > unrelated, whose name happens to be numbers.py. > > > The right answer to this is to make module search return an > error if two modules satisfy the search criteria. "First find" > isn't a good solution. > > > And thereby slowdown every single import and application startup time as > the common case of finding a module in one of the first couple entries > in sys.path now has to search it in every single item on that path. Its > not uncommon to have a LOT of things on sys.path. > > No thanks. "First Find" is good enough, especially with PEP328 and > absolute_import being on in Python 3 (and presumably 2.7). It doesn't > really help older Python versions unfortunately, but changing how import > works wouldn't help them anyways. Yeah, there might be two paths on > sys.path which both have a 'numbers.py' at the top level and First Find > might return the wrong one, but... people making poor decisions on code > organization and not using packages isn't something the language really > needs to fix. > You might want to write a script that looks through the search paths for duplicated names, especially ones which hide modules in the standard library. Has anyone done this already?
From: Ethan Furman on 5 Feb 2010 16:48
John Nagle wrote: > kj wrote: > ... >> >> Through a *lot* of trial an error I finally discovered that the >> root cause of the problem was the fact that, in the same directory >> as buggy.py, there is *another* innocuous little script, totally >> unrelated, whose name happens to be numbers.py. > > The right answer to this is to make module search return an > error if two modules satisfy the search criteria. "First find" > isn't a good solution. > > John Nagle Then what happens when you *want* to shadow a module? As MRAB suggests, if you are really concerned about it use a script that checks for duplicate modules (not a bad idea for debugging), but don't start throwing errors... next thing you know we won't be able to shadow classes, functions, or built-ins! !-) ~Ethan~ |