PEP scepticism
Carlos Ribeiro
cribeiro at mail.inet.com.br
Sat Jun 30 13:05:33 EDT 2001
At 12:53 30/06/01 +0000, Guido van Rossum wrote:
>So let's all do what we do best: the core developers (e.g. PythonLabs)
>improve the language, and the community improves the library.
If you say so it's better for us all to listen <wink>. Anyway I would like
to make a distiction concerning PythonLabs work. You are not only
responsible by the language development, but you also define the reference
distribution. Improvements on the library - either by coding new modules or
optimizing existing ones - may be made by the community, as you said, but
that's not any good if these modules don't make it to the standard
distribution.
So I believe that PythonLabs should at least consider doing three things:
- Define clearly what goes and what does not go into the standard library.
I suggest that some guidelines should be written, stating what is needed
for a module to be considered for inclusion into the standard library. The
definition itself may be fairly broad. Quality matters, and the guidelines
spec would help making the decision process more clear.
- Help track the module development process. PEPs could be used for that,
or a different mechanism to track requests could be devised. Sometimes the
community will point out the need for a new module - one that still does
not exist. In this case, a PEP-like document could be written as a kind of
"requirements spec", allowing for anyone interested in contributing to know
what kinds of modules are most requested, and how is the implementation
expected to work. PythonLabs could coordinate this effort. The actual
development could be done by anyone: PythonLabs; volunteers; or even
companies, by donating working code.
- Compile the standard modules for all supported platforms. As someone else
said, many people find it difficult to compile extension modules
themselves. I myself can't do it on my Win98 home machine, as I dont have
VC++ installed (and I doubt many users have it at home).
One advantage of having such a well defined process to elect the standard
modules is that it will encourage people to improve the standard modules,
instead of re-inventing the wheel. After seeing so many half-baked modules
around one must wonder why doesn't people contribute to the existing
alternatives. Having one recognized standard helps. The repository may also
help to solve this problem.
Carlos Ribeiro
More information about the Python-list
mailing list