[Python-Dev] Docs of weak stdlib modules should encourage exploration of 3rd-party alternatives (original) (raw)

Guido van Rossum guido at python.org
Tue Mar 13 05:40:37 CET 2012

On Mon, Mar 12, 2012 at 9:22 PM, Terry Reedy <tjreedy at udel.edu> wrote:

I would rather we figure out how to encourage authors of advancing packages to contribute better implementations of existing features and well-tested new features back to the stdlib module.

I would not. There are many excellent packages out there that should not be made into stdlib packages simply because their authors are not done adding new features. If you contribute something to the stdlib and also maintain a non-stdlib version of the same code to which you regularly add features, your code is not ready for inclusion into the stdlib. Not only should you be willing to wait 18 months (until the next feature release) before your features are released, but you should also accept that only the latest version of Python will see those features.

This obviously makes it very unattractive for many authors to ever contribute to the stdlib. That's fine. There's a healthy ecosystem of 3rd party modules. For some areas (web stuff especially) there's just no way that the stdlib can keep up. Yes, the stdlib offerings work. But no, they are not very convenient and may not support popular idioms very well. For these types of modules I think it is a good idea to place some sort of pointer in the stdlib docs to an external page (maybe a wiki page) that collects a currently popular set of alternatives, or perhaps a few pointers and wiki pages. We should still be conservative with this, and we should word it to avoid implying that the stdlib code is buggy -- it just isn't as spiffy or featureful as the 3rd party options.

(Agreed that the "leaky" wording was unfortunate. I may have inadvertently suggested this, taking the analogy with "batteries included". But I didn't mean it to be literally included into the stdlib.)

-- --Guido van Rossum (python.org/~guido)

More information about the Python-Dev mailing list