[Python-Dev] pep-3108.txt

[M.-A. Lemburg]

On 2007-01-03 01:42, Brett Cannon wrote:
> On 1/2/07, M.-A. Lemburg <mal at 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.

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.

Then again, the post is from 2002 - so things may have changed.

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.

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.

-- 
Marc-Andre Lemburg
eGenix.com

Professional Python Services directly from the Source  (#1, Jan 04 2007)
>>> Python/Zope Consulting and Support ...        http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ...             http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ...        http://python.egenix.com/
________________________________________________________________________

::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::