On 2009-04-15 19:38, James Y Knight wrote:
On Apr 15, 2009, at 12:15 PM, M.-A. Lemburg wrote:
The much more common use case is that of wanting to have a base package installation which optional add-ons that live in the same logical package namespace.
The PEP provides a way to solve this use case by giving both developers and users a standard at hand which they can follow without having to rely on some non-standard helpers and across Python implementations.
I'm not sure I understand what advantage your proposal gives over the current mechanism for doing this.
That is, add to your __init__.py file:
from pkgutil import extend_path __path__ = extend_path(__path__, __name__)
Can you describe the intended advantages over the status-quo a bit more clearly?
Simple: you don't need the above lines in your __init__.py file anymore and can rely on a Python standard for namespace packages instead of some helper implementation. The fact that you have a __pkg__.py file in your package dir will signal the namespace package character to Python's importer and this will take care of the lookup process for you. Namespace packages will be just as easy to write, install and maintain as regular Python packages. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Apr 15 2009)
Python/Zope Consulting and Support ... http://www.egenix.com/ mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
2009-03-19: Released mxODBC.Connect 1.0.1 http://python.egenix.com/ ::: Try our new mxODBC.Connect Python Database Interface 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 http://www.egenix.com/company/contact/