I agree, -1, for composability. I must also say, I find the current idiom easier to read than the proposed version, but by far the more important factor to me is the violation of composability by bundling different kinds of functionality into one call. One of the nice features of querysets.
-1 on this suggestion from me too. The current API is composable ( https://en.m.wikipedia.org/wiki/Composability ), the suggestion is to make it less so, and make it harder to learn On Sat, 19 Jan 2019 at 08:01, charettes wrote: > To echo my comments on the PR I don't like the idea of relaying
To echo my comments on the PR I don't like the idea of relaying args and kwargs to filter() as it I think it adds little value considering it paints us in a corner with regards to future count()/exists() API change. For example if we ever want to add `distinct` kwarg and fields arg passing to
Dear Sjoerd, dear all, My thoughts: * on one hand it feels natural to simplify calls and keep things simple, from this perspective +1; * on the other I can imagine new Django user that gets confused by inconsistency in code snippets or StackOverflow: you can now filter not only using filter() or
Dear all, This is probably a feature that has been proposed before, but I could not find a discussion on it, so I proposed it on the tracker, and Tim also couldn't find a discussion. (ticket: https://code.djangoproject.com/ticket/30118 ) I would like to propose being able to write