[Python-ideas] Defining an easily installable "Recommended baseline package set"

[Brendan Barnwell]

On 2017-10-29 00:54, Nick Coghlan wrote:
> The proposal in this thread thus stems from asking the question "Who is
> going to be best positioned to offer authoritative advice on which third
> party modules may be preferable to their standard library counterparts
> for end users of Python?" and answering it with "The standard library
> module maintainers that are already responsible for deciding whether or
> not to place appropriate See Also links in the module documentation".
>
> All the proposal does is to suggest taking those existing
> recommendations from the documentation and converting them into a more
> readibly executable form.

	So it sounds like you're just saying that there should be one more 
"awesome-python" style list, except it should be official, with the seal 
of approval of Python itself.  The details of exactly how that would 
displayed to users are not so important as that it be easily accessible 
from python.org and clearly shown to be endorsed by the Python developers.

	I think that is a good idea.  The current situation is quite confusing 
in many cases.  You see a lot of questions on StackOverflow where 
someone is tearing their hair out trying to use urllib to do heavy 
lifting and the answer is "use requests instead".  Likewise people 
trying to implement matrix multiplication who should probably be using 
numpy,  As for regex, to be honest, I have yet to find any way in which 
it is not completely superior to the existing re library, and I find it 
somewhat frustrating that the "publisher-side" concerns you mention 
continue to hold it back from replacing re.

	The only problem I see with this sort of "Python seal of approval" 
library list is that it carries some of the same risks as incorporating 
such libraries into the stdlib.  Not all, but some.  For one thing, if 
people go to python.org and see a thing that says "You may also want to 
use these libraries that bear the Python Seal of Approval. . .", and 
then they download them, and something goes wrong (e.g., there is some 
kind of version conflict with another package), they will likely blame 
python.org (at least partially).  Only now, since the libraries aren't 
in the stdlib, the Python devs won't really be able to do anything to 
fix that; all they could do is remove the offending package from the 
approved list.  In practice I think this is unlikely to happen, since 
the idea would be that Python devs would be judicious in awarding the 
seal of approval only to projects that are robust and not prone to 
breakage.  But it does change the nature of the approval from "we 
approve this *code* and we will fix it if it breaks" (which is how the 
existing stdlib works) to "we approve these *people* (the people working 
on requests or regex or whatever) and we will cease to do if they break 
their code".

-- 
Brendan Barnwell
"Do not follow where the path may lead.  Go, instead, where there is no 
path, and leave a trail."
    --author unknown