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
_______________________________________________
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/
