[Python-ideas] Defining an easily installable "Recommended baseline package set"
brenbarn at brenbarn.net
Sun Oct 29 13:10:21 EDT 2017
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
"Do not follow where the path may lead. Go, instead, where there is no
path, and leave a trail."
More information about the Python-ideas