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
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:
- tell people about the issue
- tell people that the fix is being installed
- 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.
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