Allow the customization of the default session creation

I'm trying to use the `sift-python` library on Google Appengine which depends on requests (https://github.com/SiftScience/sift-python/issues/52). There is the solution of using `requests-toolbelt` to monkeypatch `requests` to work on GAE, however monkeypatching would not be needed if `requests` allowed for the customization of the "session factory". Ie. in `api.request` have something like:

``` python
    with session_factory() as session:
        return session.request(method=method, url=url, **kwargs)
```

With `session_factory` having a default value of `sessions.Session`.

Then we could write code like:

``` python
from urllib3.contrib.appengine import AppEngineManager

requests.set_default_session_factory(AppEngineManager)
```


I'm honestly fairly unconvinced of the value of this. It only works if people opt-in to it in their libraries, and that's functionally equivalent to having the library you're using let you pass in a Session or SessionFactory callable. 


@Lukasa - it also works if library authors _don't opt-out_ by using the Session API. Ie. if they just write `request.get` (which I suspect most of them do) instead of setting up a session and calling methods on it, this "default session factory" would be used.

Also, perhaps some guidance in form of documentation - ie. "How to use requests if you're a library author" - could be useful. It could cover things like: allow the users of your library to customize how requests are made, to set up proxies, etc.


I have to agree with @Lukasa here.

> it also works if library authors don't opt-out by using the Session API. Ie. if they just write request.get (which I suspect most of them do) instead of setting up a session and calling methods on it, this "default session factory" would be used.

If someone is building a library that is interacting with a service using requests and not using a Session they're performing a **severe** disservice to their users. Their users are paying the performance price for the library author not using a Session. Further, if the library is not providing a way for their users to customize the session (or provide their own ready-made one) then they're also hurting their users. Poor usage of requests is not requests responsibility to fix.

> Also, perhaps some guidance in form of documentation - ie. "How to use requests if you're a library author" - could be useful. It could cover things like: allow the users of your library to customize how requests are made, to set up proxies, etc.

People don't often like to be told how to do things, and certain authors will violently disagree with what I've said above. We already have people who send pull requests to change the code-style of requests from Kenneth's style to their own personal style. The last thing we need is another avenue for people to send pull requests that are based on their own opinions of how to do a thing.

Blog posts are the better place for this kind of discussion, not Requests' documentation.


> Blog posts are the better place for this kind of discussion, not Requests' documentation.

Respectfully, I disagree.  

This paragraph belongs in the documentation, perhaps a page titled "Recommendations for Package Maintainers who use Requests":

> If someone is building a library that is interacting with a service using requests and not using a Session they're performing a severe disservice to their users. Their users are paying the performance price for the library author not using a Session. Further, if the library is not providing a way for their users to customize the session (or provide their own ready-made one) then they're also hurting their users.

Sincerely,  a library author who used `requests` the wrong way and should have used a Session but didn't, and wasted a lot more time on fixing their mistake and repackaging than I would have liked.

So I agree that *that* paragraph belongs in the documentation: I was talking about overriding the TLS config. 😉

That paragraph needs rephrasing to not be completely condescending though.

Agreed, condescension isn't a great look for us.

In an effort to clean up the issue tracker to only have issues that are still relevant to the project we've done a quick pass and decided this issue may no longer be relevant for a variety of potential reasons, including:

* Applies to a much older version, unclear whether the issue still applies.
* Change requires a backwards incompatible release and it's unclear if the benefits are worth the migration effort from the community.
* There isn't a clear demand from the community on the change landing in Requests.

If you think the issue should remain open, please comment so below or open a new issue and link back to the original issue. Again, thank you for opening the issue and for the discussion, it's much appreciated.