On Thu, Jul 21, 2011 at 11:20 PM, P.J. Eby <p...@telecommunity.com> wrote:
> This seems to lean in favor of making a simple reiterable wrapper type for
> the __path__, that only allows you to take the length and iterate over it.
>  With an appropriate design, it could actually update itself automatically,
> given a subname and a parent __path__/sys.path.  That is, it could keep a
> tuple copy of the last-seen parent path, and before iteration, compare
> tuple(self.parent_path) to self.last_seen_path.  If they're different, it
> rebuilds the value to be iterated over.
>
> Voila: transparent updating of all virtual __path__ values from sys.path
> changes (or modifications to self-contained __path__ parents, btw), and
> trying to change it (or read an item from it positionally) will not create
> any silent failures.
>
> Alright...  *if* we support automatic updates to virtual __paths__, this is
> probably how we should do it.  (It will require, though, that
> imp.find_module be changed to use a different iteration method than
> PyList_GetItem, as it's quite possible a virtual __path__ will get passed
> into it.)

A no-indexing tuple wrapper for virtual package __path__ values that
automatically updates itself in response to parent path modifications
sounds good to me (errors shall not pass silently, etc). This also
allows virtual packages to be indicated clearly just through the type
of their __path__ attribute rather than having to look them up in the
import state.

I still like the idea of keeping sys.virtual_packages as a dict
mapping to the path values, though - it makes it easier to debug
erroneous __path__ replacement in virtual packages by checking
"pkg.__path__ is sys.virtual_package_paths[pkg.__name__]"

Cheers,
Nick.

-- 
Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
_______________________________________________
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

Reply via email to