On 2008-01-06 16:33, Christian Heimes wrote:
Hello!
We are discussing name space packages on the stdlib reorg list. For Python 3.0 we plan to organize the packages by purpose, e.g. put all database related packages like sqlite and shelve in a 'databases' name space.
Regardless of whether this would really be helpful or not (I used to be in favor of this some time ago, but then realized that this doesn't really buy you anything much), please be aware that by using new generic top-level names you are likely going to get into conflict with existing applications. 'databases' will likely work since most apps will use 'database' as module or package name.
Of course we want to have the name spaces extensible by 3rd party software.
This is not a good idea. The standard lib should not be extensible by 3rd party packages, instead they should use their own top-level package and deal with whatever namespace extension mechanism is used in that package.
The Python world as currently two ways to create extensible name space packages: pkgutil and pkg_resource.
I don't think pkg_resources should go into Python 2.6 as is - for the reasons I've stated last year when this question came up. I also don't like the import mechanism hackery that's being used in setuptools to get namespace packages working. IMHO, it would be a lot cleaner to extend the existing import mechanism to support search continuation, ie. have the import find mechanism continue the search for a sub-package if it doesn't find the module in the first instance of a top-level package directory. E.g. say you want to import 'a.c' and you have directories on you sys.path: libs1/a/ libs1/a/__init__.py libs1/a/b.py libs2/a/ libs2/a/__init__.py libs2/a/c.py the import mechanism would look in libs1/a/, see that c.py is not available, then continue the search and find libs2/a/c.py. This is a sketch, but I think you get the idea. Next, we add a per-user site-packages directory to the standard sys.path, and then we could get rid of most of the setuptools import and sys.path hackery, making it a lot cleaner. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 07 2008)
Python/Zope Consulting and Support ... http://www.egenix.com/ mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
:::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,MacOSX for free ! :::: eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611