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

julien tayon julien at tayon.net
Wed Mar 14 17:16:50 CET 2012

Hello,

2012/3/13 Guido van Rossum <guido at python.org>:

On Mon, Mar 12, 2012 at 9:23 PM, Brian Curtin <brian at python.org> wrote:

Downloads don't mean the code is good. Voting is gamed. I really don't think there's a good automated solution to tell us what the high-quality replacement projects are. Sure, these are imperfect metrics. But not having any metrics at all is flawed too. Despite the huge flamewar we had 1-2 years ago about PyPI comments, I think we should follow the lead of the many app stores that pop up on the web -- users will recognize the pattern and will tune their skepticism sensors as needed.

unittest and functional testing are obctive metrics.

It it passes a unittest, and it has the same API, therefore it is a legitimate replacement for the stdlib. If a benchmark is also given that can be considered not biased and faster it is pretty neat. (but why not contribute to stdlib then?)

Functional testing is however a little more tricky, subjective and interesting. Since stdlib replacements are mostl functionnaly equivalent (like requests) of one or more stdlib module and that is what people are searching for. People willing to be considered compliant with some functionalities of a stdlib would have to give example of porting from libA to libB plus the given functionnal tests.

An interesting point may also be PEP compliance. (it is sometimes a tedious tasks when playing with SA to know if a python package of a DBDriver is DB-API 2.0 compliant).

This would make pypi even greater if package maintainers added these metadata (implements, functions_like, pep_compliance) in their setup.py given they comply with the logic. And it would pretty much automate the search for alternative to stdlib.

The huge problem is how to trust that maintainers are self disciplined enough, willing, and have enough knowledge to tag their packages properly, plus what is the extra strain on code and infrastructure to automate this ?

Without these informations we may become like senior java developpers whose greatests skills are not coding, but knowing in a wide ecosystems of packages which one are revelant/reliable/compatible/stable. (needle in a haystack)

Maybe the answer is not one of code but one of trend setting and Noise Signal Ratio on python hubs. (http://www.pythonmeme.com/, http://planet.python.org/, http://pypi.org (and still in a lesser way of classification)).

Cheers,

Julien Tayon

More information about the Python-Dev mailing list