__init__() got an unexpected keyword argument 'verify'

```
requests.session(**kwargs)
    Returns a Session for context-management.
```

This not longer works:

```
session = requests.Session(verify=not staging)

TypeError: __init__() got an unexpected keyword argument 'verify'
```


`Session` no longer takes arguments in its constructor. Currently the documentation is out of date on this.

To achieve the same effect, replace your code with this:

``` python
session = requests.Session()
session.verify = False
```

Leaving this open for a docs fix.


Indeed, the documentation needs fixing.
It was changed with rev 92355ada54a3a19341f7fbc65a8bc50816858c63.

What is the rationale for this change? It seems that the kwargs initialization is a common pattern.
With regard to the principle of least surprise, I would maintain the feature.


v1.0.0 is a breaking change, there's no requirement to maintain the API. =) Kenneth thinks this API is better/cleaner.


Nitpicking, it seems that this change is post-1.0. when I look at the commit history :-)

By the way, the second example on this page becomes obsolete. And the replacement is less elegant.
http://docs.python-requests.org/en/v1.0.0/user/advanced/#session-objects


This was not post-1.0.


Yeah, it was part of the refactoring pre-1.0.

Any chance to update the documentation before closing this ?
And there's a left-over helper which does not help anymore in requests/sessions.py at the very end.

If the decision is definitive, it should be removed to avoid confusion.

```
def session(**kwargs):
    """Returns a :class:`Session` for context-management."""

    return Session(**kwargs)
```

Thank you.


Nice catch, thanks.


Yeah, I still want to take a pass at the Sessions documentation, it's wrong. Don't need the issue open for it though.


fixed


Not in `advanced.rst` it isn't. ;) First section, entitled **Session Objects** needs a rewrite.


Not the docs, the **kwargs


Oh, balls. :frowning:


> Kenneth thinks this API is better/cleaner.

@kennethreitz 

Do you, really? If yes, can you reference any articles proposing this or libraries doing this?


@piotr-dobrogost: can you stop harassing me?


I'm not convinced at all of the benefit of this particular change of the API 1.0...
It makes some usage less simple without an obvious explanation.
And we need to freeze the dependency to requests 0.14.2 to keep the code simple.

For example this example from the documentation becomes less elegant (in my opinion)

```
headers = {'x-test': 'true'}
auth = ('user', 'pass')

with requests.session(auth=auth, headers=headers) as c:

    # both 'x-test' and 'x-test2' are sent
    c.get('http://httpbin.org/headers', headers={'x-test2': 'true'})
```


This is not up for debate. 


... said the Benevolent Dictator of Requests, without further comment.

;)


Essentially, the old code was quite complicated, hard to maintain, and included a _lot_ of duplication. Now it doesn't.


This proposal is an uncomplicated patch to make the thing more convenient for simple use cases.


No.


> can you stop harassing me?

@kennethreitz 

I can't stop doing something I never started :) Relax. Whenever somebody states (Lukasa in this case) what the other person thinks (you in this case) I want to confirm if it's really the case. That's the reason I asked if you really think this API is better/cleaner. Not using parameters in a constructor of rather complex object in object orientated language is novelty to me. That's the reason I asked about some references. As everybody can see both questions are natural and I have no idea why did you come up with this harassment thing.


@piotr-dobrogost While I do not like that decisison either API design is mainly based on a subjective point of view so there is nothing to discuss here. I have now read multiple issues in requests within the range of a few years and in all of them (!) you are trolling. Please stop doing that you are not helpful.


_I have now read multiple issues in requests within the range of a few years and in all of them (!) you are trolling._
I do not agree with your assessment but nevertheless I'm sad to hear this. Everything I write I do with good faith and if somebody feels offended in any way then I sincerely apologize. Please notice that I post in a few projects here on github and only in this one I met with negative reactions to my posts. I would like to ask you to refrain from making such generalizations in the future as they are most of the time false (this one is such a case). Also I find the word "trolling" meaningless and instead of using it I would rather describe what exactly and why do I find inappropriate.
I do find your posts and work in this project valuable and would like to remember you based on what I've seen so far and try to forget about this comment.


Thanks the two of you, but can you take this off the issue? I'm locking the issue down because it's closed and two years old.


@schlamar I would also remind you of the fact that attacks on other contributors are not welcome here. If you aren't going to be cordial towards @piotr-dobrogost and every other contributor to requests, you will not [be welcomed](http://www.kennethreitz.org/essays/be-cordial-or-be-on-your-way) here. No contributor to this project has the right to attack another and it will not be tolerated.