Add support for filter arguments in queryset.exists() and queryset.count()

[Sjoerd Job Postmus]

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
`SomeModel.objects.exists(field=value)` over
`SomeModel.objects.filter(field=value).exists()` (and similar for
`.count(**kwargs)`.


As Tim rightfully commented: "There should be one-- and preferably only
one --obvious way to do it.".


I'm proposing this is a case where the obvious way would eventually be
more in line with my suggestion instead of what we currently use.


Consider the following code example (from
https://github.com/django/django/blob/709a8b861de14204f0e13c9a0fbfd61c11b3565d/tests/auth_tests/test_management.py#L998):


            Permission.objects.filter(
                content_type__model=opts.model_name,
                content_type__app_label=opts.app_label,
                codename=codename,
            ).exists()

There is a weird (to me, your mileage might vary) ").exists()" as a
final line, and I would like to write this as

            Permission.objects.exists(
                content_type__model=opts.model_name,
                content_type__app_label=opts.app_label,
                codename=codename,
            )

This pattern seems to be quite rare in the Django codebase itself, but
in the codebase at work we have several cases of `queryset.filter(<lots
of lines>).exists()` (and similar with count), and I am expecting this
to also be prevalent in other codebases out there.


Arguing against it however are the following lines of the Zen of Python:

- "Explicit is better than implicit."

- Maybe also "Special cases aren't special enough to break the rules.",
because `.filter().count()` and `.exclude().count()` are both the same
pattern, but this would only create an alternative for the first.

- "There should be one-- and preferably only one --obvious way to do it."


Beyond these short quips, I was hoping there might also be an earlier
discussion covering this.


Kind regards,

Sjoerd Job Postmus

[Maciek Olko]

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 get() methods, from this perspective -1;

* get() already supports field lookups, so count() and exists() would join it to stand in one row, from this perspective +1;

* if introducing such change, for sure documentation should be very carefully reviewed and updated to mirror the new preferred way of doing count and exists queries;

* it would be quite a big change, I think it should be introduced with preferably MAJOR or at least MINOR version of Django;

* maybe an e-mail encouraging community to update e.g. StackOverflow with new Django syntaxt sections after the release to avoid confusion for newcomers would be a good idea?;

* what about first() and delete()? (rest of queryset methods with no arguments, that doesn't return a queryset); should they also support field lookups?

* what about reverse() and all()? (rest of queryset methods with no arguments that return a queryset); should they also support field lookups?

Kind regards,

Maciej Olko

--
You received this message because you are subscribed to the Google Groups "Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to django-develop...@googlegroups.com.
To post to this group, send email to django-d...@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/63f21e13-4c6e-89f2-aca3-6961e98832df%40sjec.nl.
For more options, visit https://groups.google.com/d/optout.

[charettes]

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 .count() in the

future (like it's Count() analog) we wouldn't be able to do so. I would consider these additions

way more in line and coherent with the current QuerySet's API.

Considering this and Tim's point about Python's Zen I'm strongly -1 on this one.

Cheers,

Simon

[Adam Johnson]

-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

--
You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to django-develop...@googlegroups.com.
To post to this group, send email to django-d...@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.

To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/1c86bd0a-0000-405b-b990-4f316bbec458%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--

Adam

[Robert Marsanyi]

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.