[Python-Dev] 3rd parties in the hierarchy (was: module reorg)

Greg Stein gstein@lyra.org
Tue, 28 Mar 2000 02:09:44 -0800 (PST)


On Tue, 28 Mar 2000, Jack Jansen wrote:
> > On Sat, 25 Mar 2000, David Ascher wrote:
> > > This made me think of one issue which is worth considering -- is there a
> > > mechanism for third-party packages to hook into the standard naming
> > > hierarchy?  It'd be weird not to have the oracle and sybase modules within
> > > the db toplevel package, for example.
> > 
> > My position is that any 3rd party module decides for itself where it wants
> > to live -- once we formalized the framework. Consider PyGTK/PyGnome,
> > PyQT/PyKDE -- they should live in the UI package too...
> 
> For separate modules, yes. For packages this is different. As a point in case 
> think of MacPython: it could stuff all mac-specific packages under the 
> toplevel "mac", but it would probably be nicer if it could extend the existing 
> namespace. It is a bit silly if mac users have to do "from mac.text.encoding 
> import macbinary" but "from text.encoding import binhex", just because BinHex 
> support happens to live in the core (purely for historical reasons).
> 
> But maybe this holds only for the platform distributions, then it shouldn't be 
> as much of a problem as there aren't that many.

Assuming that you use an archive like those found in my "small" distro or
Gordon's distro, then this is no problem. The archive simply recognizes
and maps "text.encoding.macbinary" to its own module.

Another way to say it: stop thinking in terms of the filesystem as the
sole mechanism for determining placement in the package hierarchy.

Cheers,
-g

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