On 1/4/07, M.-A. Lemburg <mal@egenix.com> wrote:
On 2007-01-03 01:42, Brett Cannon wrote:
On 1/2/07, M.-A. Lemburg <mal@egenix.com> wrote:
+Open Issues +=========== + +Consolidate dependent modules together into a single module or package? ... +Consolidate certain modules with similar themes together in a package?
+----------------------------------------------------------------------
...
If you do follow this route, please take the chance to place the whole Python stdlib under a single package. That way we'll avoid name clashes with existing packages and modules now and in the future.
That has been suggested before (including by me) and Guido has always shot it down. That's why I left it out of this proposal.
Even if it is shot down again, it still deserves to be documented together with the reasons for being shot down.
This is a one-in-a-lifetime chance, so it would be sad if it were not taken into account.
The extra effort would be minimal - the renaming would have to be done using a script anyway and adding an extra 'from py import ' prefix to the modules wouldn't really make the renaming more complicated ;-)
I was about to start writing an open issue on this since the biggest objection from Guido I could find on this topic is http://mail.python.org/pipermail/python-dev/2002-July/026409.html , but then it started to feel like a separate PEP to me. So I think I am going to pass on taking on this topic and let someone else tackle it in a PEP. Sorry, MAL, but I need to worry about my sanity on this one. =)
Oh well, it seemed like a perfect fit for the scope of PEP 3108.
I know, but I honestly just don't have the energy to deal with it. If you want to spear-head the discussion and help me add it to the PEP, then that's great. Guido's reply seems to suggest that he's in favor of introducing
a multi-package stdlib structure:
"""
I'm rejecting the proposal of a single top-level package named "python".
You've written that before, but you still haven't given any explanation of why a single package would be worse than a multi-level hierarchy of modules (e.g. grouped by application space).
Because a single package doesn't have any other benefits besides getting out of the way from 3rd party developers.
At least a proper hierarchy would have the other benefits of grouping. (But better make it a shallow hierarchy! remember "Flat is better than nested.") """
AFAICT, he was only objecting having a single package without any extra restructuring.
Yep. PEP 3108 does have some basic package suggestions in the Open Issues section and people seem to support them. I will be making a separate push for them on python-3000 once the whole discussion of what modules to remove has settled down. Then again, the post is from 2002 - so things may have changed. Maybe. There have been a couple of attempts to reorg the stdlib into
packages, but AFAIR, I see, all of them were withdrawn due to the problem of finding a suitable grouping (often enough, a module would be suitable for more than just one functional package, e.g. urllib would fit "io" as well as "net") or lack of support from the developers.
Yep, that's what has happened. Now that we're discussing moving the include files into
a subdirectory (for much the same reasons), I think it's time to reboot the discussion of a Python package with or without possible subpackages.
Well, perhaps other people want to show support if they like the idea? I am personally split down the middle either way. -Brett