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/

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/