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

2019-01-19 Thread 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.

-- 
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-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@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/a9537686-b5dd-4337-a791-31d9f2e7fbf0%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

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

2019-01-19 Thread 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

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 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
>
> Le vendredi 18 janvier 2019 15:12:22 UTC-6, Sjoerd Job Postmus a écrit :
>>
>> 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(> 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
>>
>> --
> 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-developers+unsubscr...@googlegroups.com.
> To post to this group, send email to django-developers@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--405b-b990-4f316bbec458%40googlegroups.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>


-- 
Adam

-- 
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-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@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/CAMyDDM1akghatg5AxpMf_sfEPH_FPXDShKdUJnpH9Ns3k5hh0g%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

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

2019-01-19 Thread 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

Le vendredi 18 janvier 2019 15:12:22 UTC-6, Sjoerd Job Postmus a écrit :
>
> 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( 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 
>
>

-- 
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-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@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--405b-b990-4f316bbec458%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

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

2019-01-18 Thread 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

pt., 18 sty 2019 o 22:12 użytkownik Sjoerd Job Postmus 
napisał:

> 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( 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
>
> --
> 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-developers+unsubscr...@googlegroups.com.
> To post to this group, send email to django-developers@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.
>

-- 
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-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@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/CALYYG83gUsf7uc-w8_hUVKYxd_i%3DPshguRB4VLrA-c4g2k9R6g%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

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

2019-01-18 Thread 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(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

--
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-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@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.