[Python-Dev] Thoughts on stdlib evolvement

Skip Montanaro skip at pobox.com
Tue Jun 7 01:21:11 CEST 2005


    Tim> On 6/6/05, Reinhold Birkenfeld <reinhold-birkenfeld-nospam at wolke7.net> wrote:

    >> - Flat namespace: Should we tend to a more hierarchic library (e.g.
    >> inet.url, inet.http, inet.nntp)? This would increase clarity when
    >> searching for a module.

    Tim> -1. I feel the opposite way: when trying to figure out where
    Tim> something "lives", I prefer Python's flat namespace to (for
    Tim> example) Java's com.company.baz.bar.foo hierarchy.

I think Reinhold's suggestion (e.g., inet.*) was for a flatter namespace
than Java's scheme, but for a slightly more structured namespace than the
current standard library provides.  Some amount of structure helps to
collect modules together whose names don't obviously suggest who their
neighbors are in the functionality space.  For example, to the naive user it
might not be obvious that these groups of modules and packages are related:

    * getopt and optparse
    * bsddb, gdbm and anydbm
    * email, mhlib, quopri
    * heapq, collections
    * user, site, sitecustomize
    * profile, hotshot, pstats
    * pipes, subprocess, os

I wouldn't mind a stdlib that defined a set of top-level packages (some of
which might be wholly unpopulated by modules in the standard distribution)
It might, for example, define a gui package and gui.Tkinter and gui._tkinter
modules, leaving the remainder of gui namespace available for 3rd party
modules.  Such a scheme would probably work best if there was some fairly
lightweight registration/approval process in the community to avoid needless
collisions.  For example, it might be a bit confusing if two organizations
began installing their packages in a subpackage named gui.widgets.  An
unsuspecting person downloading an application that used one version of
gui.widgets into environment with the conflicting gui.widgets would run into
trouble.  Is the CPAN namespace wide open?  If I wanted to create a Perl
module to fit into the HTML namespace is there some procedure involved or is
it an example of squatters' rights?

    >> - 3rd party modules: There are many superb modules out there, some of
    >>   which really do have a "standard" character. Examples include PIL,
    >>   numarray, ElementTree, [wxPython - I know this is a hairy issue],

    Tim> I think the most important question for each of these is "is the
    Tim> module's release schedule at least as stable as Python's?".  For
    Tim> many of these, I suspect the answer is "no".

If you provide the necessary namespace structure for them to nestle into, I
suspect most of them could be maintained outside the stdlib just fine.

Skip


More information about the Python-Dev mailing list