[Python-3000] packages in the stdlib

[Brett Cannon]

On 5/31/06, Antoine Pitrou <solipsis at pitrou.net> wrote:
>
> Le mercredi 31 mai 2006 à 09:57 -0700, Brett Cannon a écrit :
> >
> > That might be true of http, but what about modules with a more
> > ambiguous name?
>
> Then perhaps the name can be made less ambiguous ;)
> For example "ElementTree" could be named "xmltree", or whatever.


Yes, less ambiguous names, regardless of the outcome of this hierarchy
discussion, is desired by everyone.

> But with Java (don't have much .NET experience) the issue is they put
> > data structures in java.util which doesn't explain anything.  But if
> > it had been named datastruct or something more meaningful would it be
> > so bad?
>
> No, but it still would be additional baggage to remember.
> It is clear a "deque" is a collection and a "heapq" is a specific kind
> of data structure, so why try to categorize them whereas the
> categorization does not bring any additional information or
> functionality to the programmer?


I think this debate is boiling down to how people remember modules whose
name they do not have remembered.  I might remember heapq, but what happens
if I remember there is a module of implementing heaps but I don't remember
the name?  If the docs are organized in a hierarchical fashion, I can look
in one or two obvious categories.  This is made even more helpful if you are
at the interpreter prompt and you happen to have the handful of package
names memorized.  Running ``help(datastruct)`` and getting a list of
contained modules and a one-liner of what they do would be really handy.

> We are adults, but doesn't that mean we can also be organized?  We are
> > past the point of keeping our toys in one big basket and instead have
> > organized shelves where we separate our Transformers from our Tonka
> > trucks.
>
> But it is very difficult to come with a hierarchy that will be
> reasonably intuitive.


I don't know about that.  And even so, we won't have a bazillion categories,
so most of us will end up memorizing the handful that there are and what
they generally contain and use the docs and help() to figure out the rest as
needed.

Do we put "http" in "net", "protocols", "net.protocols"?
> Does "email" warrant its own package? If so, do we put "imap" or "pop3"
> in "email" or in "protocols"?
> Is "web" separate from "net"? What about "url"?
> etc.


Right, but that problem exists in a flat hierarchy as well.  Why isn't
smtplib in the email package?  What if I think that is the way it should
be?  I would then have to search again.  So this is the same as having to
peruse the docs again for smtplib.

The documentation can be topically structured, which is indeed handy
> when discovering Python and its stdlib, but why force the categorization
> on the programmer while it does not bring any benefits?



So here is how I tend to do my module searching.  When I am developing I
have an interpreter open.  I try to import a module by name to see if I got
the name right, maybe run help() on it.  If that doesn't work I pull up the
module index and look at the names for the module I want since I pretty much
know what each one does, I just don't necessarily remember the exact name.
If that fails I go to the hierarchical list or Google.

If there were categories, though, I would most likely have the handful of
package names memorized.  So I would run help() on the packages to see what
modules they had and the summary.  Basically what I should probably be doing
with the online docs' hierarchy, but entirely at the interpreter.  I
*really* prefer using the interpreter for quick doc lookup and only hit the
online docs for detailed documentation or I have no clue where something
is.  If I can cut down on the instances of not having a clue where something
is by some basic categorization at the interpreter I consider that a win.

-Brett
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.python.org/pipermail/python-3000/attachments/20060531/0364aa13/attachment-0001.html