Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Parameters are getting out of hand. #69

Closed
kennethreitz opened this issue Jun 22, 2011 · 12 comments
Closed

Parameters are getting out of hand. #69

kennethreitz opened this issue Jun 22, 2011 · 12 comments
Assignees
Labels

Comments

@kennethreitz
Copy link
Contributor

Use context manager as an alternative way to make requests?

Currently, settings context manager is a singleton. I suspect this will cause multiprocessing issues.

@jgorset
Copy link
Contributor

jgorset commented Jun 22, 2011

Interesting idea!

Are you thinking something along the lines of...

with requests.settings(path='http://example.org', timeout=10) as r:
    response = r.get('/path/to/file.txt')

...?

@kennethreitz
Copy link
Contributor Author

Heh, neat path idea.

I was thinking:

with requests.settings(timeout=10, auth=('a', 'b'), proxies={'http': 'localhost:8080'}):
    requests.get('http://blah.com/', params={'x': 'y'})

@jgorset
Copy link
Contributor

jgorset commented Jun 22, 2011

either way I think that's awesome.

@kennethreitz
Copy link
Contributor Author

Let's do it :)

@kennethreitz
Copy link
Contributor Author

Maybe this would be better:

with requests.settings(timeout=10, auth=('a', 'b'), proxies={'http': 'localhost:8080'}) as r:
    r.get('http://blah.com/')

This would escape the threading/processes issues.

@kennethreitz
Copy link
Contributor Author

If there's a way to detect if someone's using as r, then I'm all for doing it now. Otherwise, I'm going to think about it for a while.

@ghost ghost assigned kennethreitz Jun 23, 2011
@pydanny
Copy link

pydanny commented Jun 24, 2011

My thought is always that explicit is better than implicit. And intuitiveness goes along with it. So then are context processors more explicit and are they intuitive?

This does look like a divergence from the intuitive aspect of Requests that I like so much. I can point other newbies at it and they just get it. I'm open to ideas, but keep in mind your audience. Use of context processors could be for advanced users, and be given appropriate documentation.

@kennethreitz
Copy link
Contributor Author

Great points.

If I do decide to implement this, it would be supplementary. All of the functions will accept the same paramaters they do now as well.

@kennethreitz
Copy link
Contributor Author

Maybe I'll hold off on this for now.

Currently, you can do the following

>>> with requests.settings(verbose=sys.stderr):
...    requests.get('http://httpbin.org/ip')
2011-06-23T21:23:18.422726   GET   http://httpbin.org/ip
<Response [200]>

>>> requests.get('http://httpbin.org/ip')
<Response [200]>

As an alternative to:

>>> requests.settings.verbose=sys.stderr
>>> requests.get('http://httpbin.org/ip')
2011-06-23T21:23:18.422726   GET   http://httpbin.org/ip
<Response [200]>

>>> requests.settings.verbose=None
>>> requests.get('http://httpbin.org/ip')
<Response [200]>

I love this.

Maybe, it would just be best to move proxies into the settings module instead of being required to be passed into each request function for now.

@kennethreitz
Copy link
Contributor Author

Decided: current settings singleton use is a non-issue because request.settings should only manage (supplementarily) all-encompassing settings (timeouts, proxies, etc).

Auth Management still needs to be rethought.

@kennethreitz
Copy link
Contributor Author

See #75 for Re: Proxy

@kennethreitz
Copy link
Contributor Author

I'd also like to move all non-essential keyword arguments (timeout, proxies, cookies) into a well-documented and constient **kwargs again. This will solve the 'paramaters getting out of hand' issue.

Closed.

@github-actions github-actions bot locked as resolved and limited conversation to collaborators Sep 9, 2021
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Projects
None yet
Development

No branches or pull requests

3 participants