[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

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.