[Python-Dev] Letting ../site-packages override the standard lib ?!

[Greg Stein]

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
> run 
> 
> 	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
> way.

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,
problems... :-)

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).

Cheers,
-g

-- 
Greg Stein, http://www.lyra.org/