Bob Green

Sorry for the slow response - I was away last week. You may be right that it should be a = base * factor ** n but I need to...

I think this is reasonable. I worked up a PR for it here: https://github.com/litl/backoff/pull/90 I think to be consistent with other names like `max_tries` and `tries` we should probably call...

Thanks for this report. I think we should figure out how to support this use case with async for all decorators if we can.

You can also use the `giveup` keyword which allows you to inspect the exception.

You are seeing the effect of the default jitter behavior `backoff.full_jitter`. See documentation [here](https://github.com/litl/backoff#jitter). You can read more [here](https://aws.amazon.com/blogs/architecture/exponential-backoff-and-jitter/). If you don't want that behavior you can use a different...

So I think your original report was correct, and I was confused because full_jitter was on. Full jitter can cause the value to go down from one retry to the...

Woah, I just looked at my own at example more carefully and it's weirder than that. The KeyError wait generator is getting reset each time. I think combining decorators doesn't...

Do you mean some kind of API that a 3rd party library could could expose to its clients to transparently provide backoff's functionality?

Yes. It's an interesting thought. I think like you might end up wanting to expose more configuration options than just True or False though. Maybe you'd want to mirror some...

I snipped the following from the docs: > Getting exception info > > In the case of the on_exception decorator, all on_backoff and on_giveup handlers are called from within the...