[Python-ideas] Support for OAuth2/OIDC in the standard distribution ?

[Paul Moore]

On 17 November 2016 at 10:58, Cory Benfield <cory at 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