Adjust the examples to have actual side-effects #245
Conversation
Most of the examples did not any effect on the request when they should have been rate limited. This was initially deceptive as it was not clear that nothing would happen. These changes show the ways in which you can have a rate limit actually happen. I would propose that the default behavior would have the `block` option set to True but I would not do that without a larger version number change.
There was a problem hiding this comment.
thanks for this, @jensenbox! I think this will make the default behavior much more obvious—though I agree that whatever the reasons were at the time, that default is counterintuitive and should change in a major version bump.
|
Actually, #229 has been open without objection for a while, maybe it's time to just make that change, a long with publishing a v4 that actually uses the |
|
I am a new django-ratelimit user, thanks for a great package. I think it is both counter-intuitive and not clear at all from the documentation that the default behaviour when the rate is exceeded is for nothing to happen. I would support making this more explicitly visible in document and examples. |
|
Appreciate the push here, as of #269 / 4.0, this is the default. This PR definitely helped make the call to change it! |
Most of the examples did not any effect on the request when they should have been rate limited. This was initially deceptive as it was not clear that nothing would happen.
These changes show the ways in which you can have a rate limit actually happen.
I would propose that the default behavior would have the
blockoption set to True but I would not do that without a larger version number change.