@nhorelik there are a few linterissues.

My bad. Serves me right for only pip installingrequirements/requirements-testing.txt instead of the whole thing from the get-go.

Other than what's mentionedhere, do you guys follow/enforce any particular style guide? (for example, thegoogle style guide, or justpep8?)

@nhorelik mostly just keeping the linters happy.

@tomchristie@xordoquy thoughts on this? Seems like a valid enhancement to me.

Seems valid, though I feel like this is something which should be handled inget_limit (so it properly defaults).

If you setself.limit to the default inget_limit,paginate_queryset will not give you an empty result like you might expect from a limit of zero. I figured that this should act like the equivalent sql limit, which meanspaginate_queryset shouldn't use the default limit - it really should be zero there. Since the ZeroDivisionError happens inget_html_context in the calls to_divide_with_ceil at a different time in the flow, I figured it best not to changeself.limit.

If you prefer to treat a limit of zero as an invalid query param and use the defaults for everything including when paginating the queryset, then this is a one-liner fix: just setstrict=True in the call to_positive_int inget_limit.

Don't the other paginators considerlimit = 0 to be unlimited ?

We shouldn't allow users to force an unlimited queryset to be returned. Agree that an empty set makes sense.

I also think that limit=0 should be unlimited (unlimited inside themax_limit limit).
So not providinglimit makes queryset go fordefault_limit, if you providelimit=0, it goes tomax_limit. I think this is reasonable.

I made an alternative fix for this in#3990. By default, iflimit=0 query parameter is provided, it usesmax_limit as effective limit. But this behavior can be changed in a subclass. I think it is a simpler implementation than this one. And allows both desired behaviors for 0.

(Personally, I prefer to usemax_limit because one can already getdefault_limit by simply not providinglimit query parameter.)

Closed via#4194