On Thu, Jul 21, 2011 at 9:03 AM, P.J. Eby <p...@telecommunity.com> wrote: > Hm. Yes, there is a way to do something like that, but it would complicate > things a bit. We'd need to: > > 1. Leave __path__ off of the modules, and always pull them from > sys.virtual_package_paths, and
Setting __path__ to a sentinel value (imp.VirtualPath?) would break less code, as hasattr(mod, '__path__') checks would still work. Even better would be for these (and sys.path) to be list subclasses that did the right thing under the hood as Glenn suggested. Code that *replaces* rather than modifies these attributes would still potentially break virtual packages, but code that modifies them in place would do the right thing automatically. (Note that all code that manipulates sys.path and __path__ attributes requires explicit calls to correctly support current namespace package mechanisms, so this would actually be an improvement on the status quo rather than making anything worse). I'll note that this kind of thing is one of the key reasons the import state should some day move to a real class - state coherency is one of the major use cases for the descriptor protocol, which is unavailable when interdependent state is stored as module attributes. (Don't worry, that day is a very long way away, if it ever happens at all) > 2. Before using a value in sys.virtual_package_paths, we'd need to check > whether sys.path had changed since we last cached anything, and if so, clear > sys.virtual_package_paths first, to force a refresh. > > This doesn't sound particularly forbidding, but there are various unpleasant > consequences, like being unable to tell whether a module is a package or > not, and whether it's a virtual package or not. We'd have to invent new > ways to denote these things. Trying to change how packages are identified at the Python level makes PEP 382 sound positively appealing. __path__ needs to stay :) 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