New Session API feels awkward

With the old session api, one could set defaults with kwargs on session instantiation. For example, usage was similar to the following:

```
with requests.session(cookies=mycookiejar, timeout=0.5):
    ... do some work
```

This allowed one to rollup session parameters for subclasses quite nicely:

```
class MySession(object):
    def __init__(self, myparam, *args, **kwargs):
        kwargs.setdefault('auth', self)
        super(MySession, self).__init__(self, *args, **kwargs)
        self.myparam = myparam

    def __call__(self, request):
        ... perform some auth with myparam
```

However, the new api is rather awkward in that it requires these params to be painstakingly broken out:

```
with requests.session() as s:
    s.auth = myauth
    s.cookies = mycookiejar
    ...  do something with session
```

Now, I wouldn't say this new API type is a bug, but its definitely less flexible in a situation where one wants to consolidate functionality in the session object, which is common for use with APIs. It's also unclear as to why this particular change was made when moving version 1.


:+1: I agree that the new API has left something to be desired...


I don't see 'less flexible'. I could see 'more verbose' as a complaint, but 'less flexible' doesn't seem right.

The rationale (as best I understand it) for the new Session API is that it places all aspects of the Session on equal footing. There is no longer any magic in the session class upon creation, a Session can be freely modified at any stage without problem. This new API reinforces (and encourages) that behaviour.

If you don't like that API, it is simple to subclass the Session and provide a `kwarg` constructor, and I encourage you to do that. =)


I see. The `session` is treated as a mutable representation of the request context and you've locked down the avenue of mutating this state to setters. This makes the decision more clear.

> If you don't like that API, it is simple to subclass the Session and provide a kwarg constructor, and I encourage you to do that. =)

This is currently what I have done, but it does require that anything that needs to be set to be called out. It also makes subclasses less future proof because code written now to be updated to take new passthrough parameters into account.

That said, would you consider the `Session` object the right place to manage state across a set of requests?


Yes, that is the only reason it exists :)


Indeed. Conversely, should we manage "configuration" across that set of requests elsewhere?

I guess I am confused about the role of session in light of your comments on #1130. Perhaps, this discussion is better suited to the mailing list.


Basically, the session is for prescience and configuration of the requests being sent. The actual act of sending a request has different configuration though: certs, timeout, allow_redirects, etc. 

These things have nothing to do with the session. 


Excellent, so something like this would be fairly idiomatic:

```
class MyTimeoutAdapter(HTTPAdapter):
    def __init__(self, timeout=None, **kwargs):
        super(MyTimeoutAdapter, self).__init__(self, **kwargs)
        self.timeout = timeout

    def send(self, *args, **kwargs):
        kwargs.setdefault('timeout', self.timeout)
        return super(MyTimeoutAdapter, self).send(*args, **kwargs)

with requests.session() as s:
    s.mount('http://', MyTimeoutAdapter(timeout=1.0))
    ... do work
```


It's definitely how I would do it. =)