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

[Brett Cannon]

On Jan 7, 2008 2:24 PM, Raymond Hettinger <python at rcn.com> wrote:
> >> And then extend this to any other
> >> package that we consider creating? Otherwise leave it out?  How would
> >> that follow for sqlite since that is not going to get any shorter
> >> thanks to a package?  Should it still go into the package for
> >> organizational purposes?
>
> > If you're asking me, the "organizational purpose" is 100% misguided.
>
> It is my hope that there will be a great deal of restraint in the effort to group modules into packages in Py3.0.
>

There will be.  There is a reason why I am willing to let a committee
get involved with this as that will make almost any added package
difficult to pull off.

> For the most part, putting modules in packages only makes them more difficult to access and introduces an additional burden of remembering which package to invoke.
>
> The best existing indicator we have is the organization of the docs for the standard library. I, for one, have a hell of a difficult time finding modules via the "organized" table of contents in the Library Reference. Instead, I always go the the Global Module Index where the somewhat flat namespace makes it easy to go directly to the module of interest. I'm curious whether the other developers have had the same experience -- if so, then it is a bad omen for over-organizing the standard library.
>
> Another indicator of what lies ahead is the current organization of os vs os.path.  While that split-out was well done and necessary, I routinely have difficulty remembering which one contains a function of interest.
>

Yeah, 'os' could stand a reorganization, but I am not touching that one.

> There are handful of groupings that are obvious (i.e. html and socket modules going into an internet package).  Outside of those, I think it best to leave the rest of the modules in a flat namespace (I don't want to have to quess where to find queue, random, pickle, pprint, decimal, and collections.
>
> I think most of the concerns with the standard library revolve around module quality, duplication, and obsolence.

That is definitely a concern of mine and the removal of obsolete code
is still the primary motivation for me for this reorg.  But I also
realize that if we can group reasonable modules together (as you and
Guido have now both suggested based more on similarity and coming up
with shorter names) then I think we should take the chance now.

> In contrast, I do not think that introducing a hierarchy of namespaces is of interest to most users. That exercise may well make the language harder to use/learn, not easier.

I was never planning on organizing the entire stdlib into a complete,
one-level deep hierarchy.

-Brett