A RetroSearch Logo

Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Search Query:

Showing content from https://mail.python.org/pipermail/python-dev/2012-March/117548.html below:

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

[Python-Dev] Docs of weak stdlib modules should encourage exploration of 3rd-party alternativesGlenn Linderman v+python at g.nevcal.com
Tue Mar 13 19:58:13 CET 2012
On 3/13/2012 6:31 AM, Paul Moore wrote:
> 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.

+1

> 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.

+0

> 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.

+1

> There's no reason this*has*  to be in the core
> documentation - it may be relevant that nothing has sprung up
> independently yet...

Hmm.

> 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.

+1  This is the best proposal I've seen for including references to 
external modules.  It gets it in the core documentation, hopefully with 
enough keywords that search would typically find external modules that 
are supersets of stdlib modules in the same result set that the stdlib 
module would be found.  Yet it doesn't intrude on the documentation for 
the stdlib module.  And beyond a 1-2 paragraph description, would not be 
fully documented, except by referencing the external module's documentation.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20120313/135903e6/attachment.html>
More information about the Python-Dev mailing list

RetroSearch is an open source project built by @garambo | Open a GitHub Issue

Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo

HTML: 3.2 | Encoding: UTF-8 | Version: 0.7.4