Home Original page

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

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