Re: Making startproject's settings more 12-factor-y

[Kit La Touche]

I have, thank you! I tried to do my research before I wrote this email and
this PR, but there's a ton of context to all those conversations that I'm
sure I'd be missing, so I'm never gonna reach the point of feeling
confident that I have a handle on what's gone before, alas.

On Fri, Jun 5, 2020 at 4:03 PM Tim Graham  wrote:

> Have you read past discussions on the mailing list?
>
> For example:
>
> Making Django more PaaS-friendly
> https://groups.google.com/d/topic/django-developers/BAGhOKXGj4I/discussion
>
> Searching the archives for "12-factor" yields some other results.
>
> That may help you to craft your proposal.
>
> On Friday, June 5, 2020 at 5:45:07 PM UTC-4, Kit La Touche wrote:
>>
>> I'm interested in reducing the distance from running `startproject` to
>> having a deployable Django app, having recently had a number of
>> interactions with junior devs interested in using Django but finding
>> deployment a nightmare. Some of this is of course on the other side, on the
>> PaaS of choice, but some of it can (and I think should) be done on the
>> Django side.
>>
>> I'd like to start small. If I made a PR to replace a few key settings
>> with "get from the env, or fall back to this default", would people be
>> interested in approving that? I hope so!
>>
>> --Kit
>>
> --
> 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/a45204c6-5475-4ee9-a467-78c66736cfado%40googlegroups.com
> 
> .
>

-- 
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/CAFcS-hDDidkfNgDLuvLFegXUSQMAiouPU8t055qGW2KOx%3DKBSA%40mail.gmail.com.

Re: Making startproject's settings more 12-factor-y

[Tim Graham]

Have you read past discussions on the mailing list?

For example:

Making Django more PaaS-friendly
https://groups.google.com/d/topic/django-developers/BAGhOKXGj4I/discussion

Searching the archives for "12-factor" yields some other results.

That may help you to craft your proposal.

On Friday, June 5, 2020 at 5:45:07 PM UTC-4, Kit La Touche wrote:
>
> I'm interested in reducing the distance from running `startproject` to 
> having a deployable Django app, having recently had a number of 
> interactions with junior devs interested in using Django but finding 
> deployment a nightmare. Some of this is of course on the other side, on the 
> PaaS of choice, but some of it can (and I think should) be done on the 
> Django side.
>
> I'd like to start small. If I made a PR to replace a few key settings with 
> "get from the env, or fall back to this default", would people be 
> interested in approving that? I hope so!
>
> --Kit
>

-- 
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/a45204c6-5475-4ee9-a467-78c66736cfado%40googlegroups.com.

Making startproject's settings more 12-factor-y

[Kit La Touche]

I'm interested in reducing the distance from running `startproject` to
having a deployable Django app, having recently had a number of
interactions with junior devs interested in using Django but finding
deployment a nightmare. Some of this is of course on the other side, on the
PaaS of choice, but some of it can (and I think should) be done on the
Django side.

I'd like to start small. If I made a PR to replace a few key settings with
"get from the env, or fall back to this default", would people be
interested in approving that? I hope so!

--Kit

-- 
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/CAFcS-hA_YbUvsZJQNd-MD-4DfmvHwtWJfubOeOSb-46nkLPGmg%40mail.gmail.com.

Re: Implement QuerySet.__contains__?

[Shai Berger]

On Fri, 5 Jun 2020 13:58:47 +0200
Johan Schiff  wrote:

> I still think the wrong call was made here [...]
> *(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.)*
> 

FWIW, when that call was made, the default behavior was to fetch only
100 records at a time, so the performance hit for the cases you
describe was quite limited. This was changed later, as Tim mentioned in
this thread:

> Django 1.6 when chunked reads were removed from QuerySet iteration: 
> 
> https://github.com/django/django/commit/70679243d1786e03557c28929f9762a119e3ac14

-- 
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/20200605224258.783815ec.shai%40platonix.com.

Re: Implement QuerySet.__contains__?

[Tim Graham]

(You can reopen https://code.djangoproject.com/ticket/24141 rather than 
creating a new ticket.)

On Friday, June 5, 2020 at 9:06:48 AM UTC-4, Aymeric Augustin wrote:
>
> 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 > 
> 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, ‫אורי‬‎ > 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).exists():
>> אורי
>> u...@speedy.net 
>>
>>
>> On Tue, Jun 2, 2020 at 11:57 AM Johan Schiff > > 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 
>>> .
>>> To view this discussion on the web visit 
>>> https://groups.google.com/d/msgid/django-developers/88c83b8d-658c-47cc-9162-fcfebebe9c4a%40googlegroups.com
>>>  
>>> 
>>> .
>>>
>>
>> -- 
>> 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
>> .
>> To unsubscribe from this group and all its topics, 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/CABD5YeE7_ORUfJcnt6f4aB4J0j-%3DyDK_BowEt_fefcaFMGdB1g%40mail.gmail.com
>>  
>> 
>> .
>>
>
>
> -- 
> 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 .
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/django-developers/CAD69rUBKOse%2Be2RedPT%2B-KWkcdC%3DiaG0zyt1Hakefp6gQ7vdLA%40mail.gmail.com
>  
> 

Re: Implement QuerySet.__contains__?

[Aymeric Augustin]

> 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  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, ‫אורי‬‎  > 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 ).exists():
> אורי
> u...@speedy.net 
> 
> On Tue, Jun 2, 2020 at 11:57 AM Johan Schiff  > 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 
> .
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/django-developers/88c83b8d-658c-47cc-9162-fcfebebe9c4a%40googlegroups.com
>  
> .
> 
> -- 
> 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 
> .
> To unsubscribe from this group and all its topics, 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/CABD5YeE7_ORUfJcnt6f4aB4J0j-%3DyDK_BowEt_fefcaFMGdB1g%40mail.gmail.com
>  
> .
> 
> 
> -- 
> 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 
> .
> To view this discussion on the web visit 
> 

Re: Implement QuerySet.__contains__?

[Johan Schiff]

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, ‫אורי‬‎  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).exists():
> אורי
> u...@speedy.net
>
>
> On Tue, Jun 2, 2020 at 11:57 AM Johan Schiff  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.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/django-developers/88c83b8d-658c-47cc-9162-fcfebebe9c4a%40googlegroups.com
>> 
>> .
>>
> --
> 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
> .
> To unsubscribe from this group and all its topics, 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/CABD5YeE7_ORUfJcnt6f4aB4J0j-%3DyDK_BowEt_fefcaFMGdB1g%40mail.gmail.com
> 
> .
>


-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAD69rUBKOse%2Be2RedPT%2B-KWkcdC%3DiaG0zyt1Hakefp6gQ7vdLA%40mail.gmail.com.

Re: Implement QuerySet.__contains__?

[אורי]

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).exists():
אורי
u...@speedy.net


On Tue, Jun 2, 2020 at 11:57 AM Johan Schiff  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.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/88c83b8d-658c-47cc-9162-fcfebebe9c4a%40googlegroups.com
> 
> .
>

-- 
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/CABD5YeE7_ORUfJcnt6f4aB4J0j-%3DyDK_BowEt_fefcaFMGdB1g%40mail.gmail.com.

Re: Implement QuerySet.__contains__?

[Adam Johnson]

I'm with Shai, against changing bool() and len() behaviour. I think the
"fetch the whole queryset" behaviour is normally helpful for beginners, who
write things like:

if qs:
   for x in qs:
   ...

# really common for anyone new to Python:
for i in len(qs):
do_something(qs[i])

We have highlighted this behaviour for a long time in the 'database access
optimization' page really well:
https://docs.djangoproject.com/en/3.0/topics/db/optimization/#use-queryset-count
. There are alternatives if you want different behaviour - exists() and
count() .

+1 to .contains() since it would follow that same pattern.

On Fri, 5 Jun 2020 at 07:03, Shai Berger  wrote:

> On Tue, 2 Jun 2020 20:57:54 +0200
> Aymeric Augustin  wrote:
>
> >
> > We're talking about a trade-off between preserving optimisations in
> > existing code bases and expertise of advanced users versus doing the
> > right thing by default for less experienced users.
>
> I disagree.
>
> The suggestion is to make
>
> if obj in qs:
> # do things which don't fetch qs
>
> more performant, at the expense of
>
> if obj in qs:
> # do things that fetch qs
>
> As well as
>
> for obj in container:
> if obj in qs:
> # whatever
>
> So, it is not a net optimization even in terms of its own.
>
> Also, changing the performance characteristics of thousands, if not
> millions of existing lines of code, and making a decade of online
> comments and advice wrong (not just obsolete "there's better ways now"
> but wrong "this points you away from truth and good"), is IMO a
> non-starter.
>
> Strong -1 on Aymeric's option 1. Strong +1 on adding ".contains()".
>
> My 2 cents,
> Shai.
>
> --
> 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/20200605090349.559f3872.shai%40platonix.com
> .
>


-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAMyDDM1s8moPUY0dqfm3bcnFF9a7ATfz%3DDjSW2p-uXSMqvwcAg%40mail.gmail.com.

Re: What happens if a Fellow has a holiday?

[Daniel Chimeno]

Enjoy your week off!


El jueves, 4 de junio de 2020, 12:47:57 (UTC+2), Carlton Gibson escribió:
>
> Hi all. 
>
> Short answer is we don't really know, since we never take holidays. 
>
> I though am having a much needed week off from tomorrow, to be back on the 
> 16th. 
>
> Mariusz will need assistance as available *Approving changes*, from 
> Claude (our third merger) and the Technical Board, who can also Approve 
> PRs. 
> Mostly that's not needed for contributor PRs, but Mariusz makes a lot of 
> his *own PRs* as he's working, and those do need approval.
> Both these points by DEP 10.
>
> To facilitate this I have added the Django Technical Board GitHub team to 
> the django/django repo, with the non-write "Triage" role. 
> In this context, mostly this allows Mariusz to ask the TB by team handle 
> for a review. 
> (I trust this is OK.) 
>
> 3.1b1 is due on the 15th. We can delay that but... 
>
> Please can I ask the 6 of you to be aware that you might be needed. 
> Thanks. 
>
>
> Kind Regards,
>
> Carlton
>
>
>
>
>
>
>
>
>

-- 
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/e8d54466-08de-4908-9917-cf18ef89bb59o%40googlegroups.com.

Re: Implement QuerySet.__contains__?

[Shai Berger]

On Tue, 2 Jun 2020 20:57:54 +0200
Aymeric Augustin  wrote:

> 
> We're talking about a trade-off between preserving optimisations in
> existing code bases and expertise of advanced users versus doing the
> right thing by default for less experienced users.

I disagree. 

The suggestion is to make 

if obj in qs:
# do things which don't fetch qs

more performant, at the expense of

if obj in qs:
# do things that fetch qs

As well as

for obj in container:
if obj in qs:
# whatever

So, it is not a net optimization even in terms of its own.

Also, changing the performance characteristics of thousands, if not
millions of existing lines of code, and making a decade of online
comments and advice wrong (not just obsolete "there's better ways now"
but wrong "this points you away from truth and good"), is IMO a
non-starter.

Strong -1 on Aymeric's option 1. Strong +1 on adding ".contains()".

My 2 cents,
Shai.

-- 
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/20200605090349.559f3872.shai%40platonix.com.