Brett Cannon wrote:
> 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?
Hmm, much as I hate to jump on a Web bandwagon, this just rang the 'tagging'
bell in my head.
XML, for instance, would fit in the "filefmt" category, but it also fits in
categories like "datastruct", "markup", "parsing", "net" and "protocol".
If Py3k improves the ability to access metadata associated with packages and
modules (name, docstring, '__all__', etc) without actually importing the same,
then it would be possible for "help(tag='gui')" to return one line
descriptions for all modules that are marked as being 'gui' related.
Cheers,
Nick.
--
Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia
---------------------------------------------------------------
http://www.boredomandlaziness.org
_______________________________________________
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
