On 5/31/06, Antoine Pitrou <[EMAIL PROTECTED]> wrote:
Le mercredi 31 mai 2006 à 11:31 -0700, Brett Cannon a écrit :
> 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.

Ok, so we are looking for a way to easily find library modules while in
the command line, or automatically generate topical documentation.
But it doesn't mean we must mandate "from net import jabber" instead of
the more obvious "import jabber", for the common case where you already
know the module name and just want to use it.

So perhaps there is a way to create some kind of "virtual packages" or
"categories" in which existing modules could register themselves. This
could allow third-party modules (e.g. "gtk") to register themselves in
stdlib-supplied virtual packages (e.g. "gui"), for documentation and
findability purposes. "import gui; help(gui)" would give you the list of
available modules.

I see possible problems with this because then we run into your issue with packaging; where do things go?  At least with the stdlib we have sufficient control to make sure things follow a standard in terms of where thing should end up.

I would rather do an all-or-nothing solution to the whole package hierarchy for the stdlib.  Does anyone else have an opinion on any of this since this ending up just being fundamental differences in how two people like to organize modules?

-Brett
_______________________________________________
Python-3000 mailing list
Python-3000@python.org
http://mail.python.org/mailman/listinfo/python-3000
Unsubscribe: 
http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com

Reply via email to