On 7/19/2011 8:58 PM, P.J. Eby wrote:
Standard Library Changes/Additions
----------------------------------
The ``pkgutil`` module should be updated to handle this
specification appropriately, including any necessary changes to
``extend_path()``, ``iter_modules()``, etc.
Specifically the proposed changes and additions to ``pkgutil`` are:
* A new ``extend_virtual_paths(path_entry)`` function, to extend
existing, already-imported virtual packages' ``__path__`` attributes
to include any portions found in a new ``sys.path`` entry. This
function should be called by applications extending ``sys.path``
at runtime, e.g. when adding a plugin directory or an egg to the
path.
The implementation of this function does a simple top-down traversal
of ``sys.virtual_packages``, and performs any necessary
``get_subpath()`` calls to identify what path entries need to
be added to each package's ``__path__``, given that `path_entry`
has been added to ``sys.path``. (Or, in the case of sub-packages,
adding a derived subpath entry, based on their parent namespace's
``__path__``.)
When I read about creating __path__ from sys.path, I immediately thought
of the issue of programs that extend sys.path, and the above is the
"workaround" for such programs. but it requires such programs to do
work, and there are a lot of such programs (I, a relative newbie, have
had to write some). As it turns out, I can't think of a situation where
I have extended sys.path that would result in a problem for fancy
namespace packages, because so far I've only written modules, not
packages, and only modules are on the paths that I add to sys.path. But
that does not make for a general solution.
Is there some way to create a new __path__ that would reflect the fact
that it has been dynamically created, rather than set from __init__.py,
and then when it is referenced, calculate (and cache?) a new value of
__path__ to actually search?
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
