>> 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. 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. 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. 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. my-two-cents-ly, Raymond _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
