[Python-Dev] Letting ../site-packages override the standard lib ?!
Fri, 08 Sep 2000 23:31:06 +0200
Jeremy Hylton wrote:
> >>>>> "MAL" == M -A Lemburg <email@example.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!
Ok... so we'll need a more flexible solution.
> 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.
No, the problem is different: there is currently on way to
automatically add subpackages to an existing package which is
not aware of these new subpackages, i.e. say you have a
package xml in the standard lib and somebody wants to install
a new subpackage wml.
The only way to do this is by putting it into the xml
package directory (bad!) or by telling the user to
first which then does the
import xml, wml
xml.wml = wml
to complete the installation... there has to be a more elegant
Python Pages: http://www.lemburg.com/python/