How to guard against bugs like this one?
python at mrabarnett.plus.com
Fri Feb 5 21:44:58 CET 2010
Stephen Hansen wrote:
> On Fri, Feb 5, 2010 at 12:16 PM, John Nagle <nagle at animats.com
> <mailto:nagle at 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?
More information about the Python-list