phr> I don't see why you can't make up your mind enough to issue simple
phr> statements like "the Python lib should have a module that does
phr> so-and-so, and it should meet such-and-such requirements, so if
phr> someone submits one that meets the requirements and passes code
phr> review and testing and doesn't have unexpected issues or otherwise
phr> fail to meet reasonable expectations, we'll use it".
Because good requirements specification is difficult and testing improves
the breed. Better to have the major API changes and bugs taken care of, and
to have its popularity demonstrated *before* it gets into the Python
distribution. The best way to do something isn't always obvious at the
outset. If multiple solutions exist in the community, everyone benefits.
The best survive. The worst don't. If one implementation is prematurely
chosen for inclusion in the Python distribution, it stifles the vetting
process. Finally, what if, saints be preserved, your whizbang new module is
included in the core distribution and it's just not as popular as was first
thought? It just winds up as a weight around the maintainers' necks. Once
included in the distribution it's difficult to remove. Even rexec and
Bastion, which are both known to be inadequate from a security standpoint,
are still in the distribution.
So, feel free to implement whatever it is you propose. Register it with
PyPI, announce it on comp.lang.python.announce, etc. Support it for awhile.
Run it through a couple revisions to fix API warts and bugs. When it's the
category king and there is substantial community support for inclusion, it
will be considered.
Python is popular in part because of its fairly conservative development
strategy. That goes for the libraries as well as the language itself.
Skip
--
http://mail.python.org/mailman/listinfo/python-list
