[Python-Dev] Re: [Zope3-dev] Zip import and sys.path manipulation (was Re: directory hierarchy proposal)

[Moore, Paul]

Guido said:

> Time's running short (we're close to releasing Python 2.3 alpha 1);
> we should decide on a name and a specific policy ASAP.  I propose the
> following:
>=20
>   from pkgutil import extended_path
>   __path__ =3D extended_path(__path__, __name__)
>=20
> Where pkgutil.py could be something like this:
>=20
>   import sys.path
>=20
>   def extended_path(path, name):
>       """Extend a package's path.  (XXX more.)"""
>       path =3D path[:]
>       for dir in sys.path:
>           if isinstance(dir, (str, unicode)):
>               dir =3D os.path.join(dir, name)
>               if dir not in path and os.path.isdir(dir):
>                   path.append(dir)
>       return path

Are you proposing this for the standard library? It certainly
sounds reasonable, but the documentation should make clear
that it still fails for certain types of sys.path entry.

Specifically,

  - string subclasses will get converted into basic strings
  - strings which don't have a path structure wil break

(and of course, objects other than string subclasses don't get
"extended").

I don't think that either of these is even remotely a
showstopper, but they do need to be documented - specifically
because as a module, this code can be imported by anybody, and so
the constraints on the user should be made clear.

In the long term, I think the two most likely things to appear on
sys.path, apart from directory names, are

  - "Filesystem namespace extensions" like the zipfile support.
    That is, things which act like virtual directories.
  - raw importer objects

Frankly, just dumping a raw imported onto sys.path (or a package
path) is so much easier than implementing a string naming
scheme, that unless there's an overwhelmingly natural string
representation (virtual directory or URL are the only two that
come to mind) it's simpler not to bother.

So saying that module paths should only contain pathlike strings,
or importer objects, is probably reasonable. I wouldn't recommend
enforcing this, just documenting it as the normal convention.
Modules can document that they don't work with applications that
violate this convention, and relentless experimentalists still
have the freedom to break the recommendation (at their own risk!)
if they want to see what happens...

Paul.