| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
| |
get_data() API (contributed by Paul Moore)
|
|
|
|
|
|
| |
with PEP 302. This was fixed by adding an ``imp.NullImporter`` type that is
used in ``sys.path_importer_cache`` to cache non-directory paths and avoid
excessive filesystem operations during imports.
|
| |
|
|
|
|
|
| |
just ImportError. This allows documentation tools to better skip unimportable
packages.
|
| |
|
|
|
|
| |
of pkg.walk_packages. Also improve the docstrings.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
valid and
invalid file paths for the built-in import machinery which leads to
fewer open calls on startup.
Also fix issue with PEP 302 style import hooks which lead to more open()
calls than necessary.
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
to share common PEP 302 support code, as described here:
http://mail.python.org/pipermail/python-dev/2006-April/063724.html
pydoc now supports PEP 302 importers, by way of utility functions in
pkgutil, such as 'walk_packages()'. It will properly document
modules that are in zip files, and is backward compatible to Python
2.3 (setuptools installs for Python <2.5 will bundle it so pydoc
doesn't break when used with eggs.)
What has not changed is that pydoc command line options do not support
zip paths or other importer paths, and the webserver index does not
support sys.meta_path. Those are probably okay as limitations.
Tasks remaining: write docs and Misc/NEWS for pkgutil/pydoc changes,
and update setuptools to use pkgutil wherever possible, then add it
to the stdlib.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
to share common PEP 302 support code, as described here:
http://mail.python.org/pipermail/python-dev/2006-April/063724.html
This revision strips all the PEP 302 emulation code from runpy,
replacing it with published API classes and functions in pkgutil,
mostly using setuptools' implementation of common functionality,
but adding features from runpy, and doing some refactoring to make
the layer pydoc needs easier to implement on top of this.
One step down, four to go, although step #4 (adding C versions of
the new APIs to 'imp') may not be able to make it in time for
alpha 2. We'll see how that goes.
|
|
|
|
| |
(Contributed by George Yoshida.)
|
|
Here's a draft. I have no immediate use for it, but I'd like this to
be available for experimentation. I may withdraw it or change it
radically up to and including the release of Python 2.3b1.
|