[Python-Dev] [Python-checkins] r45510 - python/trunk/Lib/pkgutil.py python/trunk/Lib/pydoc.py

Phillip J. Eby pje at telecommunity.com
Tue Apr 18 17:52:57 CEST 2006


At 10:55 AM 4/18/2006 +0200, M.-A. Lemburg wrote:
>Phillip.eby wrote:
> > Author: phillip.eby
> > Date: Tue Apr 18 02:59:55 2006
> > New Revision: 45510
> >
> > Modified:
> >    python/trunk/Lib/pkgutil.py
> >    python/trunk/Lib/pydoc.py
> > Log:
> > Second phase of refactoring for runpy, pkgutil, pydoc, and setuptools
> > to share common PEP 302 support code, as described here:
> >
> > http://mail.python.org/pipermail/python-dev/2006-April/063724.html
>
>Shouldn't this new module be named "pkglib" to be in line with
>the naming scheme used for all the other utility modules, e.g. httplib,
>imaplib, poplib, etc. ?

It's not a new module; it was previously a module with only one function in 
it, introduced in Python 2.3.  If it were a new module, I'd have inquired 
about a name for it first.


> > 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.)
>
>Are you saying that the installation of setuptools in Python 2.3
>and 2.4 will then overwrite the standard pydoc included with
>those versions ?

Yes.  As far as I can tell, there were no API changes to pydoc during this 
time, so this is effectively a "hot fix".

This hot-fixing doesn't apply to setuptools system packages built with 
--root or --single-version-externally-managed, however, so OS vendors who 
build packages that wrap setuptools will have to make an explicit decision 
whether to also apply any fixes.  If they do not, an end-user can of course 
install setuptools in their local PYTHONPATH and the hotfix will take effect.


>I bothered by the fact that installing setuptools actually changes
>the standard Python installation by either overriding stdlib modules
>or monkey-patching them at setuptools import time.

Please feel free to propose alternative solutions that will still ensure 
that setuptools "just works" for end-users.  Both this and the pydoc hotfix 
are "practicality beats purity" issues.


>Add setuptools to the stdlib ? I'm still missing the PEP for this
>along with the needed discussion touching among other things,
>the change of the distutils standard "python setup.py install"
>to install an egg instead of a site package.

Setuptools in the stdlib simply means that people wanting to use it can 
import it.  It does not affect programs that do not import it.  It also 
means that "python -m easy_install" is available without having to first 
download ez_setup.py.

As for discussion, Guido originally brought up the question here a few 
months ago, and it's been listed in PEP 356 for a while.  I've also posted 
things related to the inclusion both here and in distutils-sig.



More information about the Python-Dev mailing list