> If people agree QuerySet.contains() should be added, how do we move forward?

Yes, if there's no major new argument in a couple days, we can assume consensus 
on adding .contains().

* Create a ticket in Trac. Point to this discussion and to the previous ticket 
where .contains() was suggested.
* Submit a pull request in GitHub with code, tests, docs. This is worth 
mentioning in the changelog.

There's a lot of details in the docs, in the Contributing Guide, about how to 
do allD this right.

-- 
Aymeric.



> On 5 Jun 2020, at 13:58, Johan Schiff <jo...@radkompaniet.se> wrote:
> 
> Shai does make a good point about changing a well documented behaviour. That 
> argument wins me over.
> 
> Adding .contains() and updating the documentation goes a long way to make it 
> easier for developers.
> 
> Best case would be that Dajngo does not make assumptions about what the 
> developer wants, but to implement __len__(), __bool__() and __contains__(), 
> we have to assume one method or the other. I still think the wrong call was 
> made here, but changing it now is too much pain. (Assuming queryset should be 
> evaluated is probably correct in most cases, but sometimes adds a big 
> performance hit when the code goes into production and the dataset grows - 
> code that looks reasonable and works like a charm in dev will cause trouble 
> in production. Assuming the opposite would have added a tiny performance hit 
> in most cases, but avoided the big one.)
> 
> Since I'm new here:
> If people agree QuerySet.contains() should be added, how do we move forward?
> I'd be willing to write some code with tests and add a ticket, if that's 
> helpful.
> 
> ‪Le ven. 5 juin 2020 à 11:42, ‫אורי‬‎ <u...@speedy.net 
> <mailto:u...@speedy.net>> a écrit :‬
> Hi,
> 
> I'm thinking, maybe instead of:
> 
> if obj in queryset:
> 
> Users should write:
> 
> if obj in list(queryset):
> 
> Which I understand is already working? Why does the first line (without 
> list()) should work anyway?
> 
> And if users want performance, why not write:
> 
> if queryset.filter(pk=obj.pk <http://obj.pk/>).exists():
> אורי
> u...@speedy.net <mailto:u...@speedy.net>
> 
> On Tue, Jun 2, 2020 at 11:57 AM Johan Schiff <jo...@betahaus.net 
> <mailto:jo...@betahaus.net>> wrote:
> Is there a specific reason Djangos QuerySet does not implement __contains__? 
> It doesn't seem very complicated to me, but maybe I'm missing something.
> 
> When checking if an object is in e queryset I always use code lite this:
> if queryset.filter(pk=obj.pk).exists():
> 
> The pythonic way would be:
> if obj in queryset:
> 
> The way I understand it this latter version will fetch all objects from 
> queryset, while the first one is a much leaner db query.
> 
> So, is there a reason QuerySet doesn't have a __contains__ method, or would 
> it be a good addition? My guess is that a lot of people use the "obj in 
> queryset" syntax, believing it does "the right thing".
> 
> //Johan
> 
> -- 
> 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 
> <mailto:django-developers+unsubscr...@googlegroups.com>.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/django-developers/88c83b8d-658c-47cc-9162-fcfebebe9c4a%40googlegroups.com
>  
> <https://groups.google.com/d/msgid/django-developers/88c83b8d-658c-47cc-9162-fcfebebe9c4a%40googlegroups.com?utm_medium=email&utm_source=footer>.
> 
> -- 
> You received this message because you are subscribed to a topic in the Google 
> Groups "Django developers (Contributions to Django itself)" group.
> To unsubscribe from this topic, visit 
> https://groups.google.com/d/topic/django-developers/NZaMq9BALrs/unsubscribe 
> <https://groups.google.com/d/topic/django-developers/NZaMq9BALrs/unsubscribe>.
> To unsubscribe from this group and all its topics, send an email to 
> django-developers+unsubscr...@googlegroups.com 
> <mailto:django-developers+unsubscr...@googlegroups.com>.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/django-developers/CABD5YeE7_ORUfJcnt6f4aB4J0j-%3DyDK_BowEt_fefcaFMGdB1g%40mail.gmail.com
>  
> <https://groups.google.com/d/msgid/django-developers/CABD5YeE7_ORUfJcnt6f4aB4J0j-%3DyDK_BowEt_fefcaFMGdB1g%40mail.gmail.com?utm_medium=email&utm_source=footer>.
> 
> 
> -- 
> Vänligen, Johan Schiff
> Radkompaniet AB
> 072-229 61 19
> 
> -- 
> 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 
> <mailto:django-developers+unsubscr...@googlegroups.com>.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/django-developers/CAD69rUBKOse%2Be2RedPT%2B-KWkcdC%3DiaG0zyt1Hakefp6gQ7vdLA%40mail.gmail.com
>  
> <https://groups.google.com/d/msgid/django-developers/CAD69rUBKOse%2Be2RedPT%2B-KWkcdC%3DiaG0zyt1Hakefp6gQ7vdLA%40mail.gmail.com?utm_medium=email&utm_source=footer>.

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/86269528-D48E-4C07-9426-2CCBFD7F80F7%40polytechnique.org.

Reply via email to