> On 16 Nov 2016, at 14:53, Paul Moore <p.f.mo...@gmail.com> wrote: > > I'm not a web developer as such, although I do write code that > consumes web services on occasion. I don't know what OIDC is, but I do > know, for example, that some services use OAuth. So I can imagine > being in a situation of saying "I want to get data from a web API xxx, > and it needs OAuth identification, how do I do that in Python?" > Typically, the API docs are in terms of something like Javascript, > with a browser UI, so don't help much for a command line script which > is the sort of thing I'd be writing. In that situation, a well-known, > easy to use module for OAuth in Python would be fantastic. > > Agreed that it could as easily be on PyPI as in the stdlib, but > discoverability isn't as good with PyPI - I can scan the stdlib docs, > but for PyPI I'd end up scanning Google, and what I found that way was > oauthlib - I didn't see any mention of pyoidc. I can't comment on what > that implies, though. In my brief search though I didn't find any sort > of command line "Hello world" level example.
I think this is actually another great example of why we should resist attempts to add modules to the standard library without enormous caution. I think that fundamentally in most of these cases the audience on python-dev is not equipped to decide whether an implementation deserves to become a default battery. And this is a surprisingly good example case. With all due respect to Roland, pyoidc is not the incumbent in the synchronous OAuth space: requests-oauthlib is. A quick Google search for “python oauth” turned up the following client libraries in my top 10 results: oauthlib (discarded because it’s a sans-IO implementation that recommends requests-oauthlib as a client), python-oauth2, requests-oauthlib, and Google’s OAuth 2 client library (discarded because it is bundled into the Google API client libraries module and so distorts my download counts below). A quick query of the PyPI download database for the three months shows the following download counts for those modules: - requests-oauthlib == 1,897,048 - oauth2 == 349,759 - pyoidc == 10,520 This is not intended to be chastening for Roland: all new modules start with low download counts. As the current lead maintainer of requests-oauthlib, let me say publicly and loudly that I’d love to have pyoidc replace requests-oauthlib. I *hate* requests-oauthlib. I maintain it literally only to prevent it falling into disrepair because it is extremely widely used. I would love a better library to come along so that we can sunset requests-oauthlib. I am entirely prepared to believe that Roland’s module is better than requests-oauthlib: it would be hard for it not to be. However, *right now*, pyoidc does not have anything like a majority (or even a plurality) of mindshare amongst Python developers writing OAuth clients. So why should pyoidc be added to the standard library over the competing implementations? The only reason I can see to add it is if it is a better implementation than its competitors, and the python-dev community believe that developers using the competitor implementations would be better served using pyoidc instead. Is that the case? Do we have some objective measure of this? 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. 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?”. I do not think that adding modules to the standard library is the way to answer that question. The TL;DR of this massive argument is: I think the community of people who actually use OAuth on a regular basis are better placed to judge what the best-in-class battery for OAuth is. What we need is a way to surface their collective opinions to people who don’t know what options are available, rather than to make commitments to long-term support of a module in the standard library. >> It should be noted that I believe that Python’s standard library is already >> too big, and has had a tendency in the past to expand into cases that were >> not warranted. > > I should also note that I rely heavily on the stdlib, and for a > non-trivial amount of the work I do (which is one-off scripts, not > full-blown applications) having to go outside the stdlib, other than > for a very few select modules, is a step change in complexity. So I'm > a fan of the "batteries included" approach. I think this is the other problem that needs solving, and because I’m a full-time OSS developer with complete admin rights on my development and production targets I’m badly placed to solve it. What needs to be done to make it easier for people in your position to obtain non-included batteries? Can anything be done at all? > I don't know whether OAuth is a sufficiently common requirement to > warrant going into the stdlib. My instinct is that if you're > integrating it into a web app, then there's no value in it being in > the stdlib as you'll already need 3rd party modules. If it's practical > to use OAuth from a simple Python script (say, to integrate with a web > API like github) then being in the stdlib could be a benefit. But how > many people write Python scripts that use/need OAuth? I've no feel for > that. Yeah, OAuth from Python scripts isn’t entirely uncommon. It’s mostly used to interact with third-party APIs, which usually use OAuth to allow for revocable and granular permissions grants to specific scripts. Cory _______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
