On Jan 7, 2008 2:24 PM, Raymond Hettinger <[EMAIL PROTECTED]> 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 _______________________________________________ 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
