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

[julien tayon]

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