> (CC'd to python-dev because of possible impact on zipimport
> implementation/API)
>
> At 08:00 AM 12/16/02 -0500, Jim Fulton wrote:
> >Each zope package __init__ file would have a bit of boilerplate code
> >that would include all zope directories in sys.path:
> >
> > # Boilerplate code that combines all zope directories in sys.path
> > import sys, os
> > __path__ = [os.path.join(p, 'zope') for p in sys.path]
> >
> >Jim
>
> That should probably read:
>
> __path__ = [os.path.join(p, 'zope') for p in sys.path if
> isinstance(p,StringTypes)]
>
> or else it could break in 2.3 if somebody's putting non-strings on
> sys.path. I don't remember exactly how the python-dev discussion
> turned out, but I kind of got the impression that it was going to be
> allowable in 2.3.
Correct. While the standard setup will still have only strings, we'll
support non-strings on sys.path and some users may want to use this.
> Also, I'm pretty sure it will not give the expected/desired results
> in conjunction with zipfile imports.
I think it will, actually; if /path/foo.zip is a zip file on sys.path,
/path/foo.zip/blah references a directory inside that zip file.
> For these and related reasons, I would suggest that a slightly
> different snippet be used instead (the names are lousy, improvements
> welcome):
>
> from namespace_packages import makeNamespacePath
> __path__ = makeNamespacePath('zope')
>
> And then make whatever carries "namespace_packages" be something
> that's distributed separately from Zope, preferably part of the
> standard library or distutils (and backported where possible). If
> we can make it so that the __init__ code never *has* to change, that
> will minimize the likelihood of incompatible __init__.py's floating
> around. Meanwhile, a module that actually *knows* something about
> what can be on sys.path (and how to interpret it) can do so.
This is not a bad idea: put the logic to add stuff to a package's
__path__ according to a certain policy in the standard library.
(Of course, getting it into Python 2.2 would require another release,
2.2.3 -- which may happen anyway.)
> In order to support something like this, importer objects would need
> to be able to return something that's the moral equivalent of
> "os.path.join" on an existing sys.path entry; either another
> importer object or a string that can be handled by one. At this
> point, checking for a '.zip' extension at the end of a string isn't
> going to cut it any more.
As I said above, I think it will.
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:
from pkgutil import extended_path
__path__ = extended_path(__path__, __name__)
Where pkgutil.py could be something like this:
import sys.path
def extended_path(path, name):
"""Extend a package's path. (XXX more.)"""
path = path[:]
for dir in sys.path:
if isinstance(dir, (str, unicode)):
dir = os.path.join(dir, name)
if dir not in path and os.path.isdir(dir):
path.append(dir)
return path
--Guido van Rossum (home page: http://www.python.org/~guido/)
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4