data can not be passed in session initialization

https://github.com/kennethreitz/requests/blob/develop/requests/sessions.py#L65

If `params` can be passed, shouldn't `data` be available too?

Miguel


That's a bit odd, I think.


I guess I can think of a few use cases though...


Being one passing `access_token` for OAuth2 apis. See:
https://github.com/maraujop/requests-oauth2

Cheers,
Miguel


We should talk. There's some pretty serious efforts going on to get oauth into requests right now. You should help :)


See: https://github.com/idangazit/oauthlib


I'm very surprised about this. If you re-read carefully <a href="https://github.com/kennethreitz/requests/issues/65">requests issue #65</a>, you will remember that it was me the first one trying to integrate OAuth into requests. I actually integrated the feature into requests' core the first time. But at that time, authentication needed to be polished, so you requested me to take it out and wait for the hook system.

After the hook system landed in, I redid my work turning it into a hook. I asked you what to do with it and at that time you were "leaning more towards having a requests-oauth module". After days without answer and people sending me requests to release it, I decided to create a separate repository for it.

It took you quite some time to list the module in the docs and I haven't seen you mention it publicly anywhere. Usually people list OAuth support as a first level feature in an http library. One day, out of the blue, @idangazit appeared and started complaining about an issue with cookies in my hook. I fixed it in a day. But he started talking about refactoring everything into core and adding Header authentication (which I didn't support at that time). I remember telling him: "I'm open to all the pull requests you want to send me".

Suddenly, he got assigned the task to integrate OAuth into requests' core. Several questions pop into my head: why him? why not integrating requests-oauth? How many requests libraries will benefit from a universal OAuth signing library (oauthlib)? why not reusing requests-oauth code base somehow? 

All I can say is that OAuth1.0 has more details and specifics to cover than the ones you can do in a universal signing library. Those ones take time to polish. requests-oauth2 could be merged into requests right away, as the concept of a universal library for this version of the protocol doesn't make much sense. It's orders of magnitude easier to handle and initialize.

Finally, meanwhile I was working on requests-oauth, I think I've found and submitted 4 or 5 issues in requests, for which some had patches. I also started the keepalive branch. But not a single line of code I did is included in this project.

I'm not sure why I should help in this initiative when It's my project the one that has been helping coders handle OAuth with requests for months. I've put a lot of time and effort in it already, Shouldn't it be the other way? 

When I did this specifically for requests, was because this is the future of Python's https libraries. The only thing oauthlib is covering now, that I'm missing is the provider part. I believe they are working on the provider for OAuth1.0. This is an important gap to cover in the community as there is not a single good OAuth1 Python provider.

However, more and more, OAuth2 is conquering the scene and apps like <a href="https://github.com/hiidef/oauth2app">oauth2app</a> do a decent job providing it. Sites like Github, started serving their API with OAuth2, facebook only uses OAuth2 at the moment, Twitter is planning the movement. OAuth1 will be with us for some time, probably years, but most likely it will fade away and luckily it's not the future of OAuth.

Cheers,
Miguel


I'll give a more appropriate / lengthy discussion here soon, but here's some context...

OAuthlib's goal is to be the gold standard OAuth implementation for _all_ clients, not just Requests. We just happen to be working closely together. OAuth1 and OAuth2 will be covered and all permutations thereof. All frameworks (django, flask, etc) will have shims available to utilize it on consumer and provider ends.

All of the excellent work you've done for bringing oauth into requests could be _immensely_ useful to the development of `oauthlib`, which is the best thing going forward for the Python community as a whole. Not just requests.

---

The reason your pull requests as of late have been sitting there is because they are _great_ changes that need to happen and can't be merged in immediately because of the fundamental changes they make. Normally it'd be easier, but there's underway a rearchitecture of requests / flask / werkzeug / cache / httplib / dns security libraries. This is all pretty much undocumented at this point, but I hope to fix that this week. Lots of great progress happened at PyCon. 


Other people actively involved in this are: @dgouldin, @pydanny, @ghickman, and @ib-lundgren. Dozens are passively involved. 

Here's a log of the stuff that went down at PyCon: https://github.com/pydanny/pycon2012-oauth-sprint/blob/master/index.rst

@ib-lundgren is a grad student that is hoping to do his thesis on OAuthlib, actually :)


@maraujop - A critical point of OAuthLib is to provide a library of utilities and functions audited by security people at Google, Canonical, et al. There is not a bit of requests in it, which sucks because urllib2 sucks. However, because OAuthLib is currently dependency free, that means projects that can't support requests can use it trivially. This means that not will OAuthLib be able to help replace python-oauth2 in existing systems, it can also target systems where people have cooked up their own hacky solutions because of the impossibility of dependency management.

As for OAuth2, we would love to have used that as our target. Unfortunately, as OAuth2 is not a finalized specification, that's not realistic. Even if we did it anyway, the security teams can't/won't audit it.


I think we'll have OAuth2 shortly after OAuth1 is solid. We'll have to raise some `BoundToChange` warnings though :)


@pydanny @kennethreitz I'm very aware of what oauthlib is. I totally understand its advantages, and let me insist that I've never wanted to state it's a bad project or idea. It also will ease releasing providers for different Python frameworks, something as I said is missing and that is a hard  task.

When I started requests-oauth, I wanted to add OAuth consumer ability to requests, which I guess we agree it's the future of http libraries in Python. 

I guess what I don't understand is why oauthlib started from scratch, when there were very good projects with lots of corner cases covered. The code base of those projects was a good starting point. Projects like mine or python-oauth2 (mine was based on it in the beginning), could have been refactored into a independent library. I'm guessing with the entrance of these great new devs, this is now a reality, as they are capturing their know-how in oauthlib, great.

> All of the excellent work you've done for bringing oauth into requests could be immensely useful to the development of oauthlib, which is the best thing going forward for the Python community as a whole. Not just requests.

Thanks. I'm working hard on trying to maintain my hook up to date as you know, as this is the most used choice for requests and several people depend on my development to continue working on their projects.

> The reason your pull requests as of late have been sitting there is because they are great changes that need to happen and can't be merged in immediately because of the fundamental changes they make. Normally it'd be easier, but there's underway a rearchitecture of requests / flask / werkzeug / cache / httplib / dns security libraries. This is all pretty much undocumented at this point, but I hope to fix that this week. Lots of great progress happened at PyCon.

I'm looking forward to seeing what this is all about. It felt that 27 days for getting an answer on an issue that was blocking the development of an important plugin of the application, was too long, considering 7 days before, I got an answer on an other issue #468. I know myself how busy we can all be with our lives and open source all at the same time. In your case maintaining big projects such as requests, it's even more demanding.

What I'm saying is that at the moment, requests-oauth is what people are using, until OAuth gets merged into core, there needs to be a way I can keep development alive. If I stop maintaining today my hook because something is superseding it, there will be a gap of time in which people will have no choice. I depend now on you to be able to maintain it.

Cheers,
Miguel


Closing.