@ecly thank you for preparing the PR! Agree with you that we should probably bump version number to 0.2.0 to highlight the breaking change. inspect could do, if it's not running on every request, I think it's quite an expensive call, if I recall correctly.

@ecly thank you for preparing the PR! Agree with you that we should probably bump version number to 0.2.0 to highlight the breaking change. inspect could do, if it's not running on every request, I think it's quite an expensive call, if I recall correctly.

Looking at it closer, I'm actually not even sure if it should be considered backwards incompatible.
The limit.is_exempt is already checking whether the provided function accepts a request (computed with inspect on init).

The only way in which it would break anything is if a User subclasses Limit and overrides is_exempt without the request parameter, since __evaluate_limits would call it with a request paramter.

I've added code to __evaluate_limits that can handle this, but of course any subclass that doesn't implement the request parameter would essentially be breaking the contract.

So probably 3 options:

• Ship as 0.1.10 with the changes from 8bf8b2e to make Limit subclasses without request param for is_exempt overrides still work.
• Ship as 0.2.0 without the changes from 8bf8b2e and mention it as a breaking change for Limit class, if we consider the Limit part of the public API.
• Ship as 0.1.10 without change from 8bf8b2e because we don't consider Limit.is_exempt part of public API.

Let me know which you prefer @laurentS then I'll prepare it.

Any plans to release it?

@laurentS

@ecly apologies for letting this PR rot for so long. (see #232) I'd say let's go with your first option.

@laurentS - any plans to ship this any time soon?