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

[Brian Curtin]

On Mon, Mar 12, 2012 at 21:14, Andrey Petrov <shazow at gmail.com> wrote:
> On Mon, Mar 12, 2012 at 8:58 PM, Brian Curtin <brian at python.org> wrote:
>> On Mon, Mar 12, 2012 at 19:23, Andrey Petrov <shazow at gmail.com> wrote:
>>> What such a snippet might look like:
>>>
>>> "Batteries are included with Python but sometimes they are old and
>>> leaky—this is one of those cases. Please have a look in PyPI for more modern
>>> alternatives provided by the Python community."
>>
>> What does "leaky" mean here? Someone's going to see that, think it has
>> memory leaks, then rant on the internet about how we ship crap and
>> just document it as so.
>
> I agree Brian and David, the choice of "leaky" in the wording is poor.
> It was supposed to be maintaining the "batteries" metaphor but it's
> clearly ambiguous.
>
> Perhaps something along the lines of...
>
> "Batteries are included with Python but for stability and backwards
> compatibility, some of the standard library is not always as modern as
> alternatives provided by the Python community—this is one of those
> cases. Please have a look at PyPI for more cutting-edge alternatives."

Sorry for another color choice on the bikeshed, but I would drop the
word or references to "batteries". *We* know what "batteries included"
means, but there are undoubtedly people who won't get it. It's just
code - let's call it code.

>>> Part 2:
>>> I propose we add a new category of package identifiers such as "Topic ::
>>> Standard Library Alternative :: {stdlib_package_name}" which authors of
>>> libraries can tag themselves under. The documentation warning snippet will
>>> provide a link to the appropriate PyPI query to list packages claiming to be
>>> alternatives to the stdlib package in question.
>>
>> Automating it to something on PyPI is the not the right answer. People
>> will use it incorrectly, either in that they'll add it to packages for
>> which it isn't accurate, and people just flat out won't use it or know
>> about it. It won't be accurate this way, and anything that we're
>> documenting needs to be vetted.
>>
>> It's not often that a great alternative comes up, so I don't see the
>> manual burden being too great.
>
> There are a dozen or more urllib/httplib/pycurl competitors on PyPI,
> and new ones spring up all the time. I'm not sure how we would go
> about objectively blessing the best "official" option at any given
> moment, or how frequently we would have to do this.

The same way we choose to accept libraries into the standard library.
New ones spring up all the time - mature, proven, and widely used ones
do not. If someone thinks libfoo is ready, they suggest it. If we
haven't heard of it, the conversation ends. If we have people who know
it, maybe we have them look deeper and figure out if it's something we
can put our stamp on just like we might with the recent talk of
"experimental package" inclusion.

> With self-identifying, we could sort by some sort metric (monthly
> downloads? magical score?) and create a somewhat-actionable list.

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.