[Python-Dev] pkgutil, pkg_resource and Python 3.0 name space packages

[Guido van Rossum]

On Jan 6, 2008 7:23 PM, Phillip J. Eby <pje at telecommunity.com> wrote:
> At 04:23 PM 1/6/2008 -0800, Guido van Rossum wrote:
> >Regarding using common words, either the stdlib grabs these, or
> >*nobody* gets to use them (for fear of conflicting with some other 3rd
> >party package grabbing the same).
>
> This isn't quite true; a standalone Python application that isn't
> extensible doesn't need to worry about this.  And it's standalone
> apps that are most likely to claim these common words.  (For example,
> until recently, Chandler's database library packages were in 'repository.*'.)
>
> But of course this is still a pretty minor point overall.  If the
> stdlib does go for deeper nestings, I have a slight preference for
> seeing them under std.* or some such rather than top level.  But I
> don't really see a whole lot of point to doing a major re-org of the
> stdlib space to begin with, for the simple reason that package names
> are not really categories -- they're *names*.  IMO 'from databases
> import sqlite' doesn't add any value over 'import pysqlite3' to begin with.
>
> Worse, it will likely be an attractive nuisance for people saying
> "why don't we have databases.Oracle?" and suchlike.  And you still
> have to remember the names, only now they're longer.  And was it
> database or databases?  Greater uniqueness of names is just another
> reason flat is better than nested.  :)

Right. Packages are useful if it helps make the sub-names shorter. The
email package is a good example: it uses lots of generic names like
errors, charset, encoders, message, parser, utils, iterators.

-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)