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
