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 -- http://mail.python.org/mailman/listinfo/python-list