Change decorator default from block=False to block=True

[jsocol]

Proposal: change the default from @ratelimit(block=False) to @ratelimit(block=True) in version 4.
Status: Accepted
Affects version: 4.0

Changes that would occur by default:

• When stacking ratelimits, the first limit reached would block the request and subsequent ratelimits (lower in the stack) would not be counted. Thinking about the use case of burst limits, this is probably desirable.
• Behavior would, I believe, become less surprising in common use cases.
• The default would now be less ideal for ratelimiting login screens. While this is a common use case if you're using ratelimit in exactly one place, it is probably not the majority of use cases overall. And if you're setting it up in one place, you probably have some additional work to do there, anyway.

This would not impact core.is_ratelimited(), since that method does not have a block= argument.

I suspect a number of issues over the years have been filed due to the surprising behavior of not actually blocking requests by default.

I would like to hear input from users here to know if this would make the API more intuitive or upgrading too much of a pain. The upgrade steps would be, anywhere block= is not specified and the default behavior is desired, it would need to be changed. Anywhere block=True is specified would not need to be changed.

[matthiask]

That would have been a very welcome change and would have made it easier to start using django-ratelimit for me.

A variant which may be less disruptive would be to set _sentinel = object() and block=_sentinel (or something) and warn if the block argument hasn't been specified at all while still defaulting to not blocking. Or maybe you could even drop the block=False default altogether -- requiring block to be specified explicitly, maybe as a keyword-only parameter. Existing apps would probably not even start then which is probably preferrable to silently changing the behavior. (Silently = only with a changelog entry...)

Thanks!

[jsocol]

I'd consider this comment another vote in support of the change #245 (comment)

[matthiask]

Yes, changing the documentation would certainly help. I still think there may be some value in changing the code as well.

[jsocol]

This change was made in #269, thanks for the input, folks!

[matthiask]

Thank you!