The conditonal could be cleaned up to only use one comparison; I went 
ahead and fixed that, thanks.

I don't think there's a way to avoid branching based on whether the user 
specified the total. Imagine there was no branching logic.

- if the user does not specify a total, we could set the total to 0, in 
which case it immediately wins a min(total, connect) race no matter what 
you specify there and returns.

- if the user does not specify a total, set the total to some very high 
value. Then we can't set the actual number of retries to max(total, 
connect) because the total will always be higher, we'll just retry 
infinitely.

- if the user does not specify a total, set it to _Default or similar; 
this doesn't work because in Python 3 you can't compare an object to an 
int with an object

So I think we have to branch the behavior based on whether the user 
specified a total :(

Another option is to just remove the `total` option altogether.

On 2/3/14, 3:17, Andrey Petrov wrote:
>
> In urllib3/util/retry.py:
>
> > +        """
> > +        return (response is not None
> > +                and request_method in self.method_whitelist
> > +                and response.status in self.codes_whitelist)
> > +
> > +    def is_exhausted(self):
> > +        """ Determine whether we're out of retry attempts
> > +
> > +        For each of connection errors, read errors (timeouts or bad status
> > +        codes), and redirects, compute the maximum of the specified number of
> > +        errors and the total allowable number of errors (if it was specified),
> > +        and check it against the number of errors we've seen so far.
> > +
> > +        :rtype: bool
> > +        """
> > +
>
> I'm not 100% sure what this code is doing... Shouldn't it just be...
>
> return  min(self.total,  self.connect,  self.read,  self.redirects)  <  0
>
> ?
>
> —
> Reply to this email directly or view it on GitHub 
> <https://github.com/shazow/urllib3/pull/326/files#r9373324>.
>