<br><br><div><span class="gmail_quote">On 5/31/06, <b class="gmail_sendername">Antoine Pitrou</b> <<a href="mailto:solipsis@pitrou.net">solipsis@pitrou.net</a>> wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Le mercredi 31 mai 2006 à 09:57 -0700, Brett Cannon a écrit :<br>><br>> That might be true of http, but what about modules with a more<br>> ambiguous name?<br><br>Then perhaps the name can be made less ambiguous ;)
<br>For example "ElementTree" could be named "xmltree", or whatever.</blockquote><div><br>Yes, less ambiguous names, regardless of the outcome of this hierarchy discussion, is desired by everyone.<br></div>
<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">> But with Java (don't have much .NET experience) the issue is they put<br>> data structures in
java.util which doesn't explain anything. But if<br>> it had been named datastruct or something more meaningful would it be<br>> so bad?<br><br>No, but it still would be additional baggage to remember.<br>It is clear a "deque" is a collection and a "heapq" is a specific kind
<br>of data structure, so why try to categorize them whereas the<br>categorization does not bring any additional information or<br>functionality to the programmer?</blockquote><div><br>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.
<br></div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">> We are adults, but doesn't that mean we can also be organized? We are<br>
> past the point of keeping our toys in one big basket and instead have<br>> organized shelves where we separate our Transformers from our Tonka<br>> trucks.<br><br>But it is very difficult to come with a hierarchy that will be
<br>reasonably intuitive.</blockquote><div><br>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.
</div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">Do we put "http" in "net", "protocols", "net.protocols
"?<br>Does "email" warrant its own package? If so, do we put "imap" or "pop3"<br>in "email" or in "protocols"?<br>Is "web" separate from "net"? What about "url"?
<br>etc.</blockquote><div><br>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.
<br></div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">The documentation can be topically structured, which is indeed handy<br>when discovering Python and its stdlib, but why force the categorization
<br>on the programmer while it does not bring any benefits?</blockquote><div><br><br>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.
<br><br>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.
<br></div><br>-Brett</div>