import bug

[Steven D'Aprano]

On Sat, 31 Oct 2009 16:27:20 +0000, kj wrote:

>>1) it's a bad idea to name your own modules after modules in the stdlib
> 
> Obviously, since it leads to the headaches this thread illustrates. But
> there is nothing intrisically wrong with it.  The fact that it is
> problematic in Python is a design bug, plain and simple.  There's no
> rational basis for it, 

Incorrect. Simplicity of implementation and API is a virtue, in and of 
itself. The existing module machinery is quite simple to understand, use 
and maintain. Dealing with name clashes doesn't come for free. If you 
think it does, I encourage you to write a patch implementing the 
behaviour you would prefer.

In addition, there are use-cases where the current behaviour is the 
correct behaviour. Here's one way to backport (say) functools to older 
versions of Python (untested):


# === functools.py ===

import sys

if sys.version >= '2.5':
    # Use the standard library version if it is available.
    old_path = sys.path[:]
    del sys.path[0]  # Delete the current directory.
    from functools import *
    sys.path[:] = old_path  # Restore the path.
else:
    # Backport code you want.
    pass




> and represents an unreasonable demand on module
> writers, since contrary to the tight control on reserved Python
> keywords, there does not seem to be a similar control on the names of
> stdlib modules.  What if, for example, in the future it was decided that
> my_favorite_module name would become part of the standard library?  This
> alone would cause code to break.

Not necessarily. Obviously your module my_favorite_module.py isn't 
calling the standard library version, because it didn't exist when you 
wrote it. Nor are any of your callers. Mere name clashes alone aren't 
necessarily an issue. One problem comes about when some module you import 
is modified to start using the standard library module, which conflicts 
with yours. Example:

You have a collections module, which imports the standard library stat 
module. The Python standard library can safely grow a collections module, 
but what it can't do is grow a collections module *and* modify stat to 
use that.

But in general, yes, you are correct -- there is a risk that future 
modules added to the standard library can clash with existing third party 
modules. This is one of the reasons why Python is conservative about 
adding to the std lib.

In other words, yes, module naming conflicts is the Python version of DLL 
Hell. Python doesn't distinguish between "my modules" and "standard 
modules" and "third party modules" -- they're all just modules, there 
aren't three different implementations for importing a module and you 
don't have to learn three different commands to import them. 

But there is a downside too: if you write "import os" Python has no 
possible way of knowing whether you mean the standard os.py module or 
your own os.py module.

Of course, Python does expose the import machinary to you. If avoiding 
standard library names is too much a trial for you, or if you are 
paranoid and want to future-proof your module against changes to the 
standard library (a waste of time in my opinion), you can use Python's 
import machinery to build your own system.




-- 
Steven