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