On 17 November 2016 at 10:58, Cory Benfield <c...@lukasa.co.uk> wrote: > Paul, you mentioned that discovery on PyPI is a problem: I don’t contest that > at all. But I don’t think the solution to that problem is to jam modules into > the standard library, and I think even less of that idea when there is no > formal process available for python-dev to consider the implementations > available for the standard library.
Yeah, in the process of the discussion a certain amount of context was lost. I also don't think that the solution is to "jam" modules into the standard library. I *do* think that part of the solution should be to have good solutions to common programming problems in the standard library. What is a "common problem" changes over time, as well as by problem domain, and we need to take that into account. My feeling is that (client-level, web service consumer focused) OAuth is tending towards being one of those "common problems" (as the authentication side of the whole REST/JSON/etc web API toolset) and warrants consideration for inclusion in the stdlib. I have no experience to judge what is the current "best solution". I'm happy for the community to thrash that out, and settle on a standard. Roland proposed his library as a solution - I can comment on that (from the perspective of "what a non-expert would like to have from the stdlib") but I won't until the question of "is the proposed library really the standard" is resolved. And maybe it *won't* be resolved as the situation isn't sufficiently settled yet. And that's fine. But I don't agree with the principle that we should stop adding solutions to common problems to the stdlib "because PyPI is only a pip install away". There will always be users who can't, won't or simply don't use PyPI and judge Python on what you can do with a base install. And that's a valid judgement to make. One of the reasons I prefer Python over (say) Perl, is that if I go onto a Linux server that's isolated from the internet, both are available but on Python I can do things like compose a MIME email and send it via SMTP, work with dates and times, read and write CSV files, parse XML data from an external program, etc. On Perl I can't because the Perl standard library doesn't have those things available, so I end up having to write my own - which means I take time away from getting my *actual* job done. > Instead, I think we need a way to be able to ask the question: “what does > the wider Python development community consider to be the gold standard for > solving problem X?”. Agreed, that's the key unsolved question for Python packaging. > I do not think that adding modules to the standard library is the way to > answer that question. Again agreed. But I *do* think that once that question is answered (on a case by case basis, not the overall "how do we do it for everything" question) then adding the module that has been identified as the gold standard to the stdlib *may* (depending on the problem domain) be important. Put it another way - being in the stdlib isn't a solution to the discoverability problem, but it is a solution to the access problem (which is a real problem for some people, despite pip and PyPI). Paul _______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
