On 08 September 2000, M.-A. Lemburg said:
> To provide more flexibility to the third-party tools in such
> a situation, I think it would be worthwhile moving the
> site-packages/ entry in sys.path in front of the lib/python2.0/
> entry.
>
> That way a third party tool can override the standard lib's
> package or module or take appropriate action to reintegrate
> the standard lib's package namespace into an extended one.
+0 -- I actually *like* the ability to upgrade/override bits of the
standard library; this is occasionally essential, particularly when
there are modules (or even namespaces) in the standard library that have
lives (release cycles) of their own independent of Python and its
library.
There's already a note in the Distutils README.txt about how to upgrade
the Distutils under Python 1.6/2.0; it boils down to, "rename
lib/python/2.0/distutils and then install the new version". Are PyXML,
asyncore, cPickle, etc. going to need similar qualifications in its
README? Are RPMs (and other smart installers) of these modules going to
have to include code to do the renaming for you?
Ugh. It's a proven fact that 73% of users don't read README files[1],
and I have a strong suspicion that the reliability of an RPM (or
whatever) decreases in proportion to the amount of
pre/post-install/uninstall code that it carries around with it. I think
reordering sys.path would allow people to painlessly upgrade bits of the
standard library, and the benefits of this outweigh the "but then it's
not standard anymore!" objection.
Greg
[1] And 65% of statistics are completely made up!
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