pkgutil, pkg_resource and Python 3.0 name space packages
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
On 07/01/2008, Raymond Hettinger
It is my hope that there will be a great deal of restraint in the effort to group modules into packages in Py3.0.
+1
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.
Yes, I have the same problem. I had not considered this, but I agree that it's the best indication available of how a hierarchical organisation might end up, and what issues there might be.
From the Zen of Python: "Flat is better than nested".
There are handful of groupings that are obvious (i.e. html and socket modules going into an internet package).
One man's obvious is another man's confusing. I'd stick to Guido's principle, that packages should only be used where they simplify sub-names. And even there, use restraint. I know I was earlier tending more towards the side of having more packages. I've been convinced otherwise. Paul.
At 05:24 PM 1/7/2008 -0500, Raymond Hettinger wrote:
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.
I do this too.
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.
I nearly always use my browser's search function to find the module of interest, so yes, I'm effectively using a flat namespace.
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.
I mostly remember, but there are some notable exceptions: exists (posix system call, expect to find it in os), walk (which is the old deprecated one? have to check doc). -- Andrew McNamara, Senior Developer, Object Craft http://www.object-craft.com.au/
On Jan 7, 2008 2:24 PM, Raymond Hettinger
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
participants (5)
-
Andrew McNamara -
Brett Cannon -
Paul Moore -
Phillip J. Eby -
Raymond Hettinger