Feature: allow setting of urllib3 backoff_factor

Or is it possible now from requests to set [https://github.com/kennethreitz/requests/blob/e3f89bf23c53b98593e4248054661472aacac820/requests/packages/urllib3/util/retry.py#L104](https://github.com/kennethreitz/requests/blob/e3f89bf23c53b98593e4248054661472aacac820/requests/packages/urllib3/util/retry.py#L104)?

You can use [Requests Transport Adapters](http://docs.python-requests.org/en/master/user/advanced/#transport-adapters) to do this. You only need to override the `HTTPAdapter.__init__` to set `max_retries` appropriately. Should be pretty easy.

@Lukasa No need to override `HTTPAdapter.__init__`, actually as HTTPAdapter already takes `max_retries` as an argument. (But I'm sure you already knew that, so writing it more for others than anything). 

However, I was wondering if a PR might be accepted if it consisted of making it possible to max_retries higher up. Ie in `session.send` [method](https://github.com/kennethreitz/requests/blob/master/requests/sessions.py#L599) perhaps. We could modify the adapters `max_retry` [here](https://github.com/kennethreitz/requests/blob/master/requests/sessions.py#L633). Then it could be bubbled up to the [request method](https://github.com/kennethreitz/requests/blob/master/requests/sessions.py#L440), which can be used by [`requests.get`](https://github.com/kennethreitz/requests/blob/master/requests/api.py#L61)

I've wanted to have a custom max_retries more than once and every time it feels like I need to dig into the internals. It would be nice if you could get a slightly better interface for that :). If you think this could be a viable approach I'd be willing to give a try in making a PR. 

 

I'm afraid we don't plan to add anything new to the API at this time. We jealously police the API for any new arguments because we already have a large enough number to start causing confusion: adding more just makes it worse.

We want to ensure things like these are possible, and I think we've done that. But it's just not sufficiently pressing to justify the API extension, I'm afraid.

I understand. Would you still object if max_retries was extended to `session.send`? Even that would make it a whole lot easier to work with. That way `max_retries` would still be hidden away from the top layer api and any confusion of `max_retries` would be avoided.

@Lukasa @jonathan-s My interest was spurred on by this blog post [https://stripe.com/blog/idempotency](https://stripe.com/blog/idempotency). See the "Being a good distributed citizen" section.

I don't *strongly* object to it, but it is a backward incompatible API change to do it. In this instance, I'm not sure how helpful it is to do it: are you regularly changing the value of `max_retries`?

@Lukasa I myself don't particularly care about `max_retries`. I want to easily set the [backoff_factor](https://github.com/kennethreitz/requests/blob/e3f89bf23c53b98593e4248054661472aacac820/requests/packages/urllib3/util/retry.py#L104). By default it is disabled, which is not good.

Whenever I'm writing some kind of wrapper or want to make sure that the request that I'm sending doesn't just didn't fail once I would like to change the value of `max_retries`. It's a nice feature add retries with the granularity that the `Retry` class allows you to.  

@ofek, The `max_retries` argument takes the `Retry` class which allows you to set `backoff_factor` :). 

Oh, then yes, we need the same thing!

@jonathan-s What I'm getting at is: do you have a situation where you will mostly want a default value of `max_retries` but from time-to-time will want a different one? Is there a reason that that cannot be handled with just always using the larger value of `max_retries`?