How to guard against bugs like this one?

[MRAB]

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?