[Python-Dev] module reorg (was: 1.6 job list)
Moshe Zadka <firstname.lastname@example.org>
Sat, 25 Mar 2000 21:35:37 +0200 (IST)
On Sat, 25 Mar 2000, David Ascher wrote:
> > 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...
> That sounds good in theory, but I can see possible problems down the line:
> 1) The current mapping between package names and directory structure means
> that installing a third party package hierarchy in a different place on disk
> than the standard library requires some work on the import mechanisms (this
> may have been discussed already) and a significant amount of user education.
1.a) If the work of the import-sig produces something (which I suspect it
will), it's more complicated -- you could have JAR-like files with
1.b) Installation is the domain of the distutils-sig. I seem to remember
Greg Ward saying something about installing packages.
> 2) We either need a 'registration' mechanism whereby people can claim a name
> in the standard hierarchy or expect conflicts. As far as I can gather, in
> the Perl world registration occurs by submission to CPAN. Correct?
Yes. But this is no worse then the current situation, where people pick
a toplevel name <wink>. I agree a registration mechanism would be helpful.
> One alternative is to go the Java route, which would then mean, I think,
> that some core modules are placed very high in the hierarchy (the equivalent
> of the java. subtree), and some others are deprecated to lower subtree (the
> equivalent of com.sun).
Personally, I *hate* the Java mechanism -- see Stallman's position on why
GNU Java packages use gnu.* rather then org.gnu.* for some of the reasons.
I really, really, like the Perl mechanism, and I think we would do well
to think if something like that wouldn't suit us, with minor
modifications. (Remember that lwall copied the Pythonic module mechanism,
so Perl and Python modules are quite similar)
> Anyway, I agree with Guido on this one -- naming is a contentious issue
> wrought with long-term implications. Let's not rush into a decision just
I agree. That's why I pushed out the straw-man proposal.
Moshe Zadka <email@example.com>.
http://www.linux.org.il -- we put the penguin in .com