[Python-Dev] 3rd party extensions hot-fixing the stdlib (setuptools in the stdlib)

M.-A. Lemburg mal at egenix.com
Thu Apr 20 15:19:09 CEST 2006

Phillip J. Eby wrote:
>>>>>> Why should a 3rd party extension be hot-fixing the standard
>>>>>> Python distribution ?
>>>>> Because setuptools installs things in zip files, and older versions of
>>>>> pydoc don't work for packages zip files.
>>>> That doesn't answer my question.
>>> That is the answer to the question you asked: "why hot-fix?"  Because
>>> setuptools uses zip files, and older pydocs crash when trying to display
>>> the documentation for a package (not module; modules were fine) that
is in
>>> a zip file.
>> I fail to see the relationship between setuptools and pydoc.
> People blame setuptools when pydoc doesn't work on packages in zip
> files.  Rather than refer to some theoretical argument why it's not my
> fault and I shouldn't be the one to fix it, I prefer to fix the problem.

And people come to python-dev to complain about why a Python
patch level release doesn't seem to fix some other problem
in that same code that is documented to be fixed in the release.

Don't you realize the general problem with this kind of approach ?

BTW: if setuptools would stop defaulting to using .egg
files as means of installation and instead default to using
their unzipped form, the problem would go away and setuptools
would again be in line with the Python standard of installing
modules and packages. (For the interested: see my reply to
Anthony for details or the fruitless discussions on distutils-sig
on this matter.)

>> The setuptools distribution is not the authoritative source for
>> these kinds of fixes and that should be made clear by separating
>> those parts out into a different package and making the
>> installation an explicit user option.
> ...which nobody will use, following which they will still blame
> for pydoc's failure.
> But I do agree that it might be a good idea to:
> 1) tell people about the issue
> 2) tell people that the fix is being installed
> 3) make it easy to remove the fix
> However, maybe I should just create 'pydoc-hotfix' and 'doctest-hotfix'
> packages on PyPI and then tell people to "easy_install pydoc-hotfix
> doctest-hotfix".

Yes, please !

Please use a different name for these hot-fixes, though, so
that it's clear that they only apply to specific Python
versions and are in fact, back-ports of Python 2.5 versions
of those modules.

> Or perhaps just create a "pep302-hotfixes" package that
> includes all of the PEP 302 support changes for linecache, traceback, and
> so on, although I'm not sure how many of those can be installed in such a
> way that the fixes would be active prior to the stdlib versions being
> I suppose I could handle the "nobody will use it" problem by having
> easy_install nag about the hotfixes not being installed when running
> 2.3 or 2.4.

Fair enough.

>> You should also note that users won't benefit from bug fixed
>> versions of e.g. such modules in patch level releases.
> The pydoc fixes to support zip files are too extensive to justify
> backporting, as they rely on features provided elsewhere.  So if bug
> occur on the 2.5 trunk, I would have to update the hotfix versions


Marc-Andre Lemburg

Professional Python Services directly from the Source  (#1, Apr 20 2006)
>>> Python/Zope Consulting and Support ...        http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ...             http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ...        http://python.egenix.com/

::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::

More information about the Python-Dev mailing list