[Python-Dev] Thoughts on stdlib evolvement

Reinhold Birkenfeld reinhold-birkenfeld-nospam at wolke7.net
Tue Jun 7 19:40:49 CEST 2005

Skip Montanaro wrote:
>     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

Yep, exactly. Java's namespaces are ugly, that's right, but a flatter version
certainly improves readability.
"""Namespaces are one honking great idea -- let's do more of those!"""

> 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?

Personally, I think that CPAN is one of the greatest strengths of Perl. The language
is a mess, and the quality of many modules is questionable, but it's incredibly
easy to find a module for handling a special problem, and the namespaces are IMHO
well thought out. Additionally, the docs

>     >> - 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.

Exactly! There needn't be such a big separation between stdlib and 3rd party.
Access to the net is standard nowadays, though it wouldn't be of any harm
making a big distribution with all modules available, for downloading and burning
on CD, for example.

PJE's great EasyInstall and Python Eggs will be a perfect starting point for this,
I think.


Mail address is perfectly valid!

More information about the Python-Dev mailing list