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