[Python-Dev] Letting ../site-packages override the standard lib ?!
Fri, 8 Sep 2000 16:08:55 -0700
On Fri, Sep 08, 2000 at 11:31:06PM +0200, M.-A. Lemburg wrote:
> Jeremy Hylton wrote:
> > 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.
> 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
> import xml_wml
> first which then does the
> import xml, wml
> xml.wml = wml
> to complete the installation... there has to be a more elegant
There is. I proposed it a while back. Fred chose to use a different
mechanism, despite my recommendations to the contrary. *shrug*
The "current" mechanism require the PyXML package to completely override the
entire xml package in the Python distribution. This has certain, um,
Another approach would be to use the __path__ symbol. I dislike that for
various import design reasons, but it would solve one of the issues Fred had
with my recommendation (e.g. needing to pre-import subpackages).
Greg Stein, http://www.lyra.org/