[Python-Dev] Letting ../site-packages override the standard lib ?!
Jeremy Hylton
jeremy@beopen.com
Fri, 8 Sep 2000 16:54:33 -0400 (EDT)
>>>>> "MAL" == M -A Lemburg <mal@lemburg.com> writes:
MAL> To provide more flexibility to the third-party tools in such a
MAL> situation, I think it would be worthwhile moving the
MAL> site-packages/ entry in sys.path in front of the lib/python2.0/
MAL> entry.
MAL> That way a third party tool can override the standard lib's
MAL> package or module or take appropriate action to reintegrate the
MAL> standard lib's package namespace into an extended one.
MAL> What do you think ?
I think it is a bad idea to encourage third party tools to override
the standard library. We call it the standard library for a reason!
It invites confusion and headaches to read a bit of code that says
"import pickle" and have its meaning depend on what oddball packages
someone has installed on the system. Good bye, portability!
If you want to use a third-party package that provides the same
interface as a standard library, it seems much clearn to say so
explicitly.
I would agree that there is an interesting design problem here. I
think the problem is support interfaces, where an interface allows me
to write code that can run with any implementation of that interface.
I don't think hacking sys.path is a good solution.
Jeremy