[Python-Dev] Thoughts on stdlib evolvement
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,
Mail address is perfectly valid!
More information about the Python-Dev