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

Paul Moore p.f.moore at gmail.com
Tue Mar 13 14:31:38 CET 2012

On 13 March 2012 03:48, C. Titus Brown <ctb at msu.edu> wrote:

I feel like there's a middle ground where stable, long-term go-to modules could be mentioned, though.  I don't spend a lot of time browsing PyPI, but I suspect almost everyone spends a certain amount of time in the Python docs (which is a testimony to their quality IMO).  So I'm in favor of conservative link-outs but without any deprecating language.

I applaud the idea of promoting the many excellent packages available. It can be very hard to separate the good from the indifferent (or even bad) when browsing PyPI. I've found some very good packages recently which I'd never have known about without some random comment on a mailing list.

However, I'm not keen on having the stdlib documentation suggest that I should be using something else. No code should ever be documenting "don't use me, there are better alternatives" unless it is deprecated or obsolete.

On the other hand, I would love to see a community-maintained document that described packages that are acknowledged as "best of breed". That applies whether or not those packages replace something in the stdlib. Things like pywin32, lxml, and requests would be examples in my experience. There's no reason this has to be in the core documentation - it may be relevant that nothing has sprung up independently yet...

Maybe a separate item in the Python documentation, "External Modules", could be created and maintained by the community? By being in the documentation, it has a level of "official recommendation" status, and by being a top-level document it's visible (more so than, for example, a HOWTO document would be). Because it's in the released documentation, it is relatively stable, which implies that external modules would need to have a genuine track record to get in there, but because it's community maintained it should reflect a wider consensus than just the core developers' views.

Paul.

More information about the Python-Dev mailing list