Implement QuerySet.__contains__?

[Johan Schiff]

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.

Re: Implement QuerySet.__contains__?

[Aymeric Augustin]

Hello Johan,

You explained the upside. There's one downside to be aware of. If you already 
fetched the queryset, `if obj in queryset` will make a new database query, 
which will be slower than walking through the already fetched data (unless the 
queryset is really large and the database really close in terms of network 
latency). Making this change may throw off some assertNumQueries tests. 
However, people who consider this a regression can do `obj in list(queryset)` 
or perhaps `obj in iter(queryset)` to reuse the cached list.

Judgment call: I think the upside is worth the downside and 
backwards-incompatibility, so I'm in favor of the change.

Best regards,

-- 
Aymeric.



> On 2 Jun 2020, at 10:57, 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/570372E7-2949-426C-BAAE-DBEF1B17FBC0%40polytechnique.org.

Re: Implement QuerySet.__contains__?

[Adam Johnson]

>
> If you already fetched the queryset, `if obj in queryset` will make a new
> database query


I don't see why we couldn't implement __contains__ to do a walk through
_result_cache if it has been fetched?

On Tue, 2 Jun 2020 at 10:13, Aymeric Augustin <
aymeric.augus...@polytechnique.org> wrote:

> Hello Johan,
>
> You explained the upside. There's one downside to be aware of. If you
> already fetched the queryset, `if obj in queryset` will make a new database
> query, which will be slower than walking through the already fetched data
> (unless the queryset is really large and the database really close in terms
> of network latency). Making this change may throw off some assertNumQueries
> tests. However, people who consider this a regression can do `obj in
> list(queryset)` or perhaps `obj in iter(queryset)` to reuse the cached list.
>
> Judgment call: I think the upside is worth the downside and
> backwards-incompatibility, so I'm in favor of the change.
>
> Best regards,
>
> --
> Aymeric.
>
>
>
> On 2 Jun 2020, at 10:57, 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/570372E7-2949-426C-BAAE-DBEF1B17FBC0%40polytechnique.org
> 
> .
>


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

Re: Fellow Reports -- May 2020

[Carlton Gibson]

Hi all. 



Calendar Week 22 -- ending 31 May.


Preparation for 2.2.13 and 3.0.7 releases. 


Triaged:

https://code.djangoproject.com/ticket/31635 -- SameSite cookie except on a 
URL (wontfix)



Reviewed:

https://github.com/django/django/pull/12978 -- Refs #31040, Refs #31224 -- 
Prevented cycles in exceptions chain.
https://github.com/django/django/pull/12988 -- Fixed isolation of 
test_migrate_fake_initial.
https://github.com/django/django/pull/12970 -- Updated how to install 
Django on windows docs
https://github.com/django/django/pull/12981 -- Fixed #31628 -- Updated 
Windows install guide to recommend venv.



Authored:

https://github.com/django/django/pull/12990 -- Fixed #31570 -- Corrected 
translation loading for apps providing only a subset of supported languages.




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/fa23f973-eae2-4190-a551-cbcfa50db667%40googlegroups.com.

Re: Implement QuerySet.__contains__?

[Florian Apolloner]

On Tuesday, June 2, 2020 at 11:28:34 AM UTC+2, Adam Johnson wrote:
>
> If you already fetched the queryset, `if obj in queryset` will make a new 
>> database query
>
>
> I don't see why we couldn't implement __contains__ to do a walk through 
> _result_cache if it has been fetched?
>

we are doing the same for len() IIRC. I have to say it sometimes makes it a 
little bit hard to debug, but if it is documented as such it should be okay.

-- 
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/fa0eae17-2c25-4ae2-befb-c20ebfb8d1da%40googlegroups.com.

Re: Implement QuerySet.__contains__?

[Aymeric Augustin]

> On 2 Jun 2020, at 13:30, Florian Apolloner  wrote:
> 
> On Tuesday, June 2, 2020 at 11:28:34 AM UTC+2, Adam Johnson wrote:
> If you already fetched the queryset, `if obj in queryset` will make a new 
> database query
> 
> I don't see why we couldn't implement __contains__ to do a walk through 
> _result_cache if it has been fetched?
> 
> we are doing the same for len() IIRC. I have to say it sometimes makes it a 
> little bit hard to debug, but if it is documented as such it should be okay.

These are good points.

As far as I can tell, the current implementation of __len__ is to fetch the 
whole queryset:

def __len__(self):
self._fetch_all()
return len(self._result_cache)

I'm almost sure doing an automatic .count() was discussed in the past. I don't 
remember why we rejected it — perhaps because in most cases, when you need the 
length of a queryset, you will also iterate it?

The suggestion for __contains__ is similar: doing an automatic 
.filter(pk=obj.pk).exists(). We could do it only if the queryset isn't fetched 
yet, but I'm afraid this may be too magical. Is it reasonable to have `total = 
len(queryset); found = obj in queryset` make one SQL query while `found = obj 
in queryset; total = len(queryset)` makes two queries?

Now I'm worried that we may be making inconsistent decisions between __len__ 
and __contains__... Let's make sure we're consistent across dunder methods.

-- 
Aymeric


-- 
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/9B25C8F3-A282-4C7F-BB4C-252364514A03%40polytechnique.org.

Re: Implement QuerySet.__contains__?

[Tim Graham]

It may help to know that QuerySet.__contains__() was implemented until 
Django 1.6 when chunked reads were removed from QuerySet iteration: 

https://github.com/django/django/commit/70679243d1786e03557c28929f9762a119e3ac14

On Tuesday, June 2, 2020 at 7:43:25 AM UTC-4, Aymeric Augustin wrote:
>
> On 2 Jun 2020, at 13:30, Florian Apolloner  > wrote:
>
> On Tuesday, June 2, 2020 at 11:28:34 AM UTC+2, Adam Johnson wrote:
>>
>> If you already fetched the queryset, `if obj in queryset` will make a new 
>>> database query
>>
>>
>> I don't see why we couldn't implement __contains__ to do a walk through 
>> _result_cache if it has been fetched?
>>
>
> we are doing the same for len() IIRC. I have to say it sometimes makes it 
> a little bit hard to debug, but if it is documented as such it should be 
> okay.
>
>
> These are good points.
>
> As far as I can tell, the current implementation of __len__ is to fetch 
> the whole queryset:
>
> def __len__(self):
> self._fetch_all()
> return len(self._result_cache)
>
> I'm almost sure doing an automatic .count() was discussed in the past. I 
> don't remember why we rejected it — perhaps because in most cases, when you 
> need the length of a queryset, you will also iterate it?
>
> The suggestion for __contains__ is similar: doing an automatic .filter(pk=
> obj.pk).exists(). We could do it only if the queryset isn't fetched yet, 
> but I'm afraid this may be too magical. Is it reasonable to have `total = 
> len(queryset); found = obj in queryset` make one SQL query while `found = 
> obj in queryset; total = len(queryset)` makes two queries?
>
> Now I'm worried that we may be making inconsistent decisions between 
> __len__ and __contains__... Let's make sure we're consistent across dunder 
> methods.
>
> -- 
> Aymeric
>
>
>

-- 
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/55b4d7e0-ba30-48b2-8005-d27adacc7fd0%40googlegroups.com.

Re: Implement QuerySet.__contains__?

[Roger Gammans]

Hi,
Here are some performance numbers against a local SQLite in case any
one is interested. GL has about 40,000 records for reference.324 was
just a random number chosen, of different 'in's 

>>> sys.version'3.7.2rc1 (default, Dec 12 2018, 06:25:49) \n[GCC
8.2.0]'>>> django.__version__'3.0.6'>>> import myapp.models as m>>> x =
m.GL.objects.all()[324]>>> x in m.GL.objects.all()True
>>> import timeit>>> timeit.timeit('m.GL.objects.filter(pk=x.pk)',
setup='import myapp.models as m;x = m.GL.objects.all()[324]',
number=100)0.05818330496549606>>> timeit.timeit('x in qs',
setup='import myapp.models as m;qs = m.GL.objects.all(); x=qs[324]',
number=100)1.5688817161135375


On Tue, 2020-06-02 at 05:53 -0700, Tim Graham wrote:
> It may help to know that QuerySet.__contains__() was implemented
> until Django 1.6 when chunked reads were removed from QuerySet
> iteration:
> 
> https://github.com/django/django/commit/70679243d1786e03557c28929f9762a119e3ac14
> On Tuesday, June 2, 2020 at 7:43:25 AM UTC-4, Aymeric Augustin wrote:
> > > On 2 Jun 2020, at 13:30, Florian Apolloner 
> > > wrote:
> > > 
> > > On Tuesday, June 2, 2020 at 11:28:34 AM UTC+2, Adam Johnson
> > > wrote:
> > > > > If you already fetched the queryset, `if obj in queryset`
> > > > > will make a new database query
> > > > 
> > > > I don't see why we couldn't implement __contains__ to do a walk
> > > > through _result_cache if it has been fetched?
> > > > 
> > > 
> > > we are doing the same for len() IIRC. I have to say it sometimes
> > > makes it a little bit hard to debug, but if it is documented as
> > > such it should be okay.
> > 
> > These are good points.
> > 
> > As far as I can tell, the current implementation of __len__ is to
> > fetch the whole queryset:
> > 
> > def __len__(self):
> > self._fetch_all()
> > return len(self._result_cache)
> > 
> > I'm almost sure doing an automatic .count() was discussed in the
> > past. I don't remember why we rejected it — perhaps because in most
> > cases, when you need the length of a queryset, you will also
> > iterate it?
> > 
> > The suggestion for __contains__ is similar: doing an automatic
> > .filter(pk=obj.pk).exists(). We could do it only if the queryset
> > isn't fetched yet, but I'm afraid this may be too magical. Is it
> > reasonable to have `total = len(queryset); found = obj in queryset`
> > make one SQL query while `found = obj in queryset; total =
> > len(queryset)` makes two queries?
> > 
> > Now I'm worried that we may be making inconsistent decisions
> > between __len__ and __contains__... Let's make sure we're
> > consistent across dunder methods.
> > 
> > -- 
> > Aymeric
> > 
> > 
> 
> 
> 
> -- 
> 
> 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/55b4d7e0-ba30-48b2-8005-d27adacc7fd0%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/69fdfe26be34d37a09cfe9dc7f5cc9a4c580d1d9.camel%40gammascience.co.uk.

Re: Implement QuerySet.__contains__?

[Tim Graham]

And here's some past discussion:
https://code.djangoproject.com/ticket/24141 - contains() method for 
QuerySets (closed as needsinfo due to no mailing list discussion to find a 
consensus)
https://github.com/django/django/pull/3906 - Efficient 
QuerySet.__contains__ (closed as wontfix due to the behavior change)

On Tuesday, June 2, 2020 at 8:53:07 AM UTC-4, Tim Graham wrote:
>
> It may help to know that QuerySet.__contains__() was implemented until 
> Django 1.6 when chunked reads were removed from QuerySet iteration: 
>
>
> https://github.com/django/django/commit/70679243d1786e03557c28929f9762a119e3ac14
>
> On Tuesday, June 2, 2020 at 7:43:25 AM UTC-4, Aymeric Augustin wrote:
>>
>> On 2 Jun 2020, at 13:30, Florian Apolloner  wrote:
>>
>> On Tuesday, June 2, 2020 at 11:28:34 AM UTC+2, Adam Johnson wrote:
>>>
>>> If you already fetched the queryset, `if obj in queryset` will make a 
 new database query
>>>
>>>
>>> I don't see why we couldn't implement __contains__ to do a walk through 
>>> _result_cache if it has been fetched?
>>>
>>
>> we are doing the same for len() IIRC. I have to say it sometimes makes it 
>> a little bit hard to debug, but if it is documented as such it should be 
>> okay.
>>
>>
>> These are good points.
>>
>> As far as I can tell, the current implementation of __len__ is to fetch 
>> the whole queryset:
>>
>> def __len__(self):
>> self._fetch_all()
>> return len(self._result_cache)
>>
>> I'm almost sure doing an automatic .count() was discussed in the past. I 
>> don't remember why we rejected it — perhaps because in most cases, when you 
>> need the length of a queryset, you will also iterate it?
>>
>> The suggestion for __contains__ is similar: doing an automatic .filter(pk=
>> obj.pk).exists(). We could do it only if the queryset isn't fetched yet, 
>> but I'm afraid this may be too magical. Is it reasonable to have `total = 
>> len(queryset); found = obj in queryset` make one SQL query while `found = 
>> obj in queryset; total = len(queryset)` makes two queries?
>>
>> Now I'm worried that we may be making inconsistent decisions between 
>> __len__ and __contains__... Let's make sure we're consistent across dunder 
>> methods.
>>
>> -- 
>> Aymeric
>>
>>
>>

-- 
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/5e16c857-d3c1-4d9d-b7cd-99fe77b7e13a%40googlegroups.com.

Re: Implement QuerySet.__contains__?

[Javier Buzzi]

My 2 cents, I think @johan's suggestion makes sense.

if obj in queryset:

It's very pythonic. it should do what __len__ does and cache it, if you 
want the single quick db query you can always use exists().


ps @roger

>>> timeit.timeit('m.GL.objects.filter(pk=x.pk)', setup='import 
myapp.models as m;x = m.GL.objects.all()[324]', number=100)
0.05818330496549606

is not doing anything, add a `.exists()` or `len(..)` or something to evaluate 
the queryset. That number is WAY too low.

-- 
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/5195eb58-8600-43a3-ad46-1c72f691f04b%40googlegroups.com.

Dynamic SESSION_COOKIE_DOMAIN and CSRF_COOKIE_DOMAIN settings

[Kevin Grinberg]

Hi folks,

I recently ran into an issue around the SESSION_COOKIE_DOMAIN and 
CSRF_COOKIE_DOMAIN settings that seems like it could be fixable by adding 
some extensibility.

Before submitting a patch/PR, I wanted to get the community's opinion on 
whether this is worth addressing in the framework, or if it's adding 
complexity for an audience of ~1.

The issue is that I needed to set SESSION_COOKIE_DOMAIN and 
CSRF_COOKIE_DOMAIN to a different value depending on the request's Host 
header.

For example, imagine the same Django app serving two domains with two 
subdomains, e.g.:

  www.example.com and api.example.com
  www.example2.com and api.example2.com

For each request to *.example.com, I want to set SESSION_COOKIE_DOMAIN and 
CSRF_COOKIE_DOMAIN to 'example.com', and vice-versa for requests to 
*.example2.com

As it stands, if I set SESSION_COOKIE_DOMAIN and CSRF_COOKIE_DOMAIN to None 
(the default behavior), the cookie domain will be the full request host - 
so api.example.com won't see cookies from www.example.com, and vice-versa. 
Thus, if I want cross-domain cookies, I need to set 
[SESSION|CSRF]_COOKIE_DOMAIN to e.g. 'example.com' so that it's sent for 
both domains.

Right now, the only way to do that is by overriding CsrfViewMiddleware and 
SessionMiddleware almost wholesale, because the references to 
SESSION_COOKIE_DOMAIN and CSRF_COOKIE_DOMAIN are buried inside the 
middlewares' process_request/process_response methods.

I propose that this could be addressed by adding an e.g. 
'get_cookie_domain' method to CsrfViewMiddleware and SessionMiddleware, 
which projects could override to get the sort of custom behavior I'm trying 
to enable here (the default would of course be to return the setting, as it 
does now).

I've considered and dismissed some alternative approaches - this seems like 
the cleanest way of accomplishing this without introducing a ton of new 
complexity.

I recognize that CSRF and session behavior is particularly fraught with 
security implications, so I wanted to throw this out to the community and 
see if there were any strong feelings one way or another before moving 
forward with a PR.

Cheers,
Kevin

-- 
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/0c16e9e4-b588-4cd0-ba9a-8c1287e6a193%40googlegroups.com.

Re: Implement QuerySet.__contains__?

[Aymeric Augustin]

> On 2 Jun 2020, at 19:42, Tim Graham  wrote:
> 
> And here's some past discussion:
> https://code.djangoproject.com/ticket/24141 - contains() method for QuerySets 
> (closed as needsinfo due to no mailing list discussion to find a consensus)
> https://github.com/django/django/pull/3906 - Efficient QuerySet.__contains__ 
> (closed as wontfix due to the behavior change)

Thanks. Your memory is amazing :-)

Since the issue keeps coming back, I think we should do one of the following:

1. make simultaneous and consistent changes to __nonzero__, __len__, and 
__contains__ to eliminate the "fetch the whole table" behavior when calling `if 
qs`,  `len(qs)` and `if obj in qs` — and check if any other special methods 
require similar treatment
2. failing that, add .contains(), as suggested in 
https://code.djangoproject.com/ticket/24141

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 think we're increasingly willing to 
consider changes that make Django safer to use, so perhaps what Carl said in 
2015 could be open for discussion. If I forget what I know about querysets for 
a minute, the Principle of Least Astonishment says we should go for option 1.

if qs:  # test in qs isn't empty
if list(qs):  # fetch and cache qs, then test if it isn't empty
len(qs): # count the number of objects in qs
len(list(qs)):  # fetch and cache qs, then count the number of objects
if obj in qs:  # test if qs contains obj
if obj in list(qs):  # fetch and cache qs, then test if qs contains obj

objects = list(qs) is a well known pattern when you need to trigger the 
database query, perhaps because you'll do further manipulations in Python.

In https://code.djangoproject.com/ticket/18702#comment:8 
 Anssi says he was in 
favor of committing the optimized version (my option 1). Just before finalizing 
his patch, he changed his mind because:

- "This approach optimizes use cases that are rare": well, since they keep 
coming up, in fact they aren't so rare
- "Special casing some uses makes the code complex": sure, but the whole point 
of Django is to include _some_ complexity so that users have less to worry 
about.

I'm interested in what others think :-)

-- 
Aymeric.




-- 
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/90C68EF9-7343-44D6-9BB0-33972198685A%40polytechnique.org.

Re: Fellow Reports - May 2020

[Mariusz Felisiak]

Week ending May 31, 2020.

*Triaged:*
https://code.djangoproject.com/ticket/31617 - Improve overall admin 
accessibility. (Someday/Maybe)
https://code.djangoproject.com/ticket/31622 - Support CREATE CONSTRAINT 
TRIGGER constraints in postgres. (wontfix)
https://code.djangoproject.com/ticket/31620 - Support "%V" format in 
WeekArchiveView. (accepted)
https://code.djangoproject.com/ticket/30952 - KeyError: 
'_password_reset_token' during password reset. (needsinfo)
https://code.djangoproject.com/ticket/31610 - Make it easier to override 
the RelatedFieldWidgetWrapper in admin. (wontfix)
https://code.djangoproject.com/ticket/31616 - Add hint to the E410 about 
AuthenticationMiddleware. (accepted)
https://code.djangoproject.com/ticket/31630 - Replace 
DatabaseFeatures.introspected_*_field_type attributes with a single 
attribute. (accepted)
https://code.djangoproject.com/ticket/31627 - Could there be an "--exclude" 
option to "startproject/startapp"? (invalid)
https://code.djangoproject.com/ticket/31621 - Add "--parallel=auto" option 
to the "test" command. (accepted)
https://code.djangoproject.com/ticket/31631 - Use Django ORM Postgresql 
regex when the regex is in the database and the value is a string 
(duplicate)
https://code.djangoproject.com/ticket/31636 - BooleanFieldListFilter 
doesn't respect field choices. (accepted)
https://code.djangoproject.com/ticket/13068 - The "Add another [inline 
object]" javascript doesn't respect prepopulated_fields settings (fixed)

*Reviewed/committed:*
https://github.com/django/django/pull/12965 - Fixed #31624 -- Avoided 
subquery usage on QuerySet.all().delete().
https://github.com/django/django/pull/12966 - Fixed #29078 -- Made 
serializers respect prefetch_related() for m2m fields.
https://github.com/django/django/pull/12974 - Refs #23097 -- Used new octal 
format in FILE_UPLOAD_PERMISSIONS docs.
https://github.com/django/django/pull/12973 - Fixed #31616 -- Added hint 
about middleware ordering for SessionMiddleware admin check.
https://github.com/django/django/pull/12754 - Fixed #31416 -- Made 
autodetector find dependencies for MTI model creation on base fields 
removal.
https://github.com/django/django/pull/12961 - Fixed #31614 -- Fixed aliases 
ordering by OrderBy() expressions of combined queryset.
https://github.com/django/django/pull/12951 - Fixed #31606 -- Allowed using 
condition with lookups in When() expression.
https://github.com/django/django/pull/12917 - Fixed #31494 -- Preserved 
query strings when following HTTP 307/308 redirects in test client.
https://github.com/django/django/pull/12952 - Fixed #31615 -- Made 
migrations skip extension operations if not needed.
https://github.com/django/django/pull/12945 - Fixed #11157 -- Stopped 
removing stop words in admin's prepopulated_fields.
https://github.com/django/django/pull/12921 - Refs #31034 -- Improved 
accessibility of admin navigation sidebar.
https://github.com/django/django/pull/12131 - Fixed #31468 -- Allowed 
specifying migration filename in Operation.
https://github.com/django/django/pull/12983 - Fixed #28694 -- Made 
django.utils.text.slugify() strip dashes and underscores.
https://github.com/django/django/pull/12982 - Refs #21171 -- Made 
Collector.delete() rollback in the correct database.

*Authored:*
https://github.com/django/django/pull/12978 - Refs #31040, Refs #31224 -- 
Prevented cycles in exceptions chain.

Best regards,
Mariusz

-- 
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/8ec6224b-b00f-437f-a1e1-6576afa74300%40googlegroups.com.

Re: Implement QuerySet.__contains__?

[Roger Gammans]

On Tue, 2020-06-02 at 11:31 -0700, Javier Buzzi wrote:
> ps @roger
> 
> >>> timeit.timeit('m.GL.objects.filter(pk=x.pk)', setup='import
> myapp.models as m;x = m.GL.objects.all()[324]', number=100)
> 0.05818330496549606
> 
> is not doing anything, add a `.exists()` or `len(..)` or something to
> evaluate the queryset. That number is WAY too low.

Yes, of course. That makes me feel silly, on both counts - the
evaluations and the number of iterations.  I made number of iterations
low;because I started with a test which a single iteration was taking
multiple seconds and it that case the default number was way to high
for the quick test I was offering. More critically the x in qs; depends
on where in the qs the object is and it doesn't matter how big if you
only look at the beginning.
I reran it; but which shows different results.. See the following re
run. Construction here is more complicated to show avg microsecs; per
iteration, note the vary iteration lengths, actual runtime was aimed to
be between 20secs and a minute or so.
>>> # Searching for first in queryset>>> n=10_000_000 ;timeit.timeit('x
in qs', setup='import myapp.models as m;qs = m.GL.objects.all();
qs2=qs;i=len(qs2);x=qs[0]',
number=n)/(n/1_000_000)0.4136358265765011>>> n = 100_000 ;
timeit.timeit('m.GL.objects.filter(pk=x.pk)', setup='import
myapp.models as m;x =
list(m.GL.objects.all())[0]',  number=n)/(n/1_000_000)124.9944525491446
3>>> # Searching for last in queryset.>>> n=1000; timeit.timeit('x in
qs', setup='import myapp.models as m;qs = m.GL.objects.all();
qs2=qs;i=len(qs2);x=qs[i-1]',
number=n)/(n/1_000_000)50741.098549216986>>> n = 100_000 ;
timeit.timeit('m.GL.objects.filter(pk=x.pk)', setup='import
myapp.models as m;x = list(m.GL.objects.all())[-
1]',  number=n)/(n/1_000_000)118.99649207945913


-- 
Roger Gammans 

-- 
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/3928039038bac9b52279294f7efcac318dc80388.camel%40gammascience.co.uk.

Re: Dynamic SESSION_COOKIE_DOMAIN and CSRF_COOKIE_DOMAIN settings

[Adam Johnson]

You can already achieve what you're aiming to do in an outer middleware by
mutating the cookie in response.cookies. The cookie object can have its
domain changed before it is sent to the client:

>>> from django.http import HttpResponse
>>> resp = HttpResponse()
>>> resp.set_cookie('foo', 'bar', domain='example.com')
>>> resp.cookies

>>> resp.cookies['foo']

>>> resp.cookies['foo'].update({'domain':'example.org'})
>>> resp.cookies['foo']


In this way, you could even leave the setting as None and instead use an
outer middleware to set the domain appropriately based on
request.headers['host'] , for requests where the cookie is being set. You
can even do it automatically for all outgoing cookies.


On Tue, 2 Jun 2020 at 19:40, Kevin Grinberg 
wrote:

> Hi folks,
>
> I recently ran into an issue around the SESSION_COOKIE_DOMAIN and
> CSRF_COOKIE_DOMAIN settings that seems like it could be fixable by adding
> some extensibility.
>
> Before submitting a patch/PR, I wanted to get the community's opinion on
> whether this is worth addressing in the framework, or if it's adding
> complexity for an audience of ~1.
>
> The issue is that I needed to set SESSION_COOKIE_DOMAIN and
> CSRF_COOKIE_DOMAIN to a different value depending on the request's Host
> header.
>
> For example, imagine the same Django app serving two domains with two
> subdomains, e.g.:
>
>   www.example.com and api.example.com
>   www.example2.com and api.example2.com
>
> For each request to *.example.com, I want to set SESSION_COOKIE_DOMAIN
> and CSRF_COOKIE_DOMAIN to 'example.com', and vice-versa for requests to *.
> example2.com
>
> As it stands, if I set SESSION_COOKIE_DOMAIN and CSRF_COOKIE_DOMAIN to
> None (the default behavior), the cookie domain will be the full request
> host - so api.example.com won't see cookies from www.example.com, and
> vice-versa. Thus, if I want cross-domain cookies, I need to set
> [SESSION|CSRF]_COOKIE_DOMAIN to e.g. 'example.com' so that it's sent for
> both domains.
>
> Right now, the only way to do that is by overriding CsrfViewMiddleware and
> SessionMiddleware almost wholesale, because the references to
> SESSION_COOKIE_DOMAIN and CSRF_COOKIE_DOMAIN are buried inside the
> middlewares' process_request/process_response methods.
>
> I propose that this could be addressed by adding an e.g.
> 'get_cookie_domain' method to CsrfViewMiddleware and SessionMiddleware,
> which projects could override to get the sort of custom behavior I'm trying
> to enable here (the default would of course be to return the setting, as it
> does now).
>
> I've considered and dismissed some alternative approaches - this seems
> like the cleanest way of accomplishing this without introducing a ton of
> new complexity.
>
> I recognize that CSRF and session behavior is particularly fraught with
> security implications, so I wanted to throw this out to the community and
> see if there were any strong feelings one way or another before moving
> forward with a PR.
>
> Cheers,
> Kevin
>
> --
> 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/0c16e9e4-b588-4cd0-ba9a-8c1287e6a193%40googlegroups.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/CAMyDDM2Td0ogYkQWVQ6dge_uRiWC_a6-qxcDVYXzTJB1uRrpXg%40mail.gmail.com.

Django and Vuejs

[P.E.A.K.A.]

hello for everyone
?how can i use from vuejs in django

-- 
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/8589df17-49c3-47fc-bfb2-6ed8ead81a19%40googlegroups.com.

Re: Django and Vuejs

[Kacper Szmigiel]

Hello!

The answer is "yes", but this question was asked on a wrong mailing list.
Consider writing to Django users mailing lists.

Regards,
Kacper

śr., 3 cze 2020 o 00:06 P.E.A.K.A.  napisał(a):

> hello for everyone
> ?how can i use from vuejs in django
>
> --
> 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/8589df17-49c3-47fc-bfb2-6ed8ead81a19%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/CAFfZ%2Bb5RoFTfgxaz%2BXmr59AxtX_xS1_rqtKCjxxqA8k1RCs%3DhQ%40mail.gmail.com.

Re: Django and Vuejs

[Kacper Szmigiel]

Uh, sorry, I haven't noticed that the question was "how", dummy me. There
are several ways to do this, as I wrote consider asking on proper mailing
list, this one is focused on developing Django framework itself.

Regards,
Kacper

śr., 3 cze 2020 o 00:20 Kacper Szmigiel 
napisał(a):

> Hello!
>
> The answer is "yes", but this question was asked on a wrong mailing list.
> Consider writing to Django users mailing lists.
>
> Regards,
> Kacper
>
> śr., 3 cze 2020 o 00:06 P.E.A.K.A. 
> napisał(a):
>
>> hello for everyone
>> ?how can i use from vuejs in django
>>
>> --
>> 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/8589df17-49c3-47fc-bfb2-6ed8ead81a19%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/CAFfZ%2Bb6%3Dxd6DkAj5yaR_JtmigcfeFXmNsD6MJE2iuKTS74eiow%40mail.gmail.com.

Re: Django and Vuejs

[Adam Johnson]

Hi!

I think you've found the wrong mailing list for this post. This mailing
list is for discussing the development of Django itself, not for support
using Django. This means the discussions of bugs and features in Django
itself, rather than in your code using it. People on this list are unlikely
to answer your support query with their limited time and energy.

For support, please follow the "Getting Help" page:
https://docs.djangoproject.com/en/3.0/faq/help/ . This will help you find
people who are willing to support you, and to ask your question in a way
that makes it easy for them to answer.

Thanks for your understanding and all the best,

Adam

On Tue, 2 Jun 2020 at 23:22, Kacper Szmigiel 
wrote:

> Uh, sorry, I haven't noticed that the question was "how", dummy me. There
> are several ways to do this, as I wrote consider asking on proper mailing
> list, this one is focused on developing Django framework itself.
>
> Regards,
> Kacper
>
> śr., 3 cze 2020 o 00:20 Kacper Szmigiel 
> napisał(a):
>
>> Hello!
>>
>> The answer is "yes", but this question was asked on a wrong mailing list.
>> Consider writing to Django users mailing lists.
>>
>> Regards,
>> Kacper
>>
>> śr., 3 cze 2020 o 00:06 P.E.A.K.A. 
>> napisał(a):
>>
>>> hello for everyone
>>> ?how can i use from vuejs in django
>>>
>>> --
>>> 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/8589df17-49c3-47fc-bfb2-6ed8ead81a19%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/CAFfZ%2Bb6%3Dxd6DkAj5yaR_JtmigcfeFXmNsD6MJE2iuKTS74eiow%40mail.gmail.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/CAMyDDM0k4Q%2BvJGfw6nwpSsQhY-pgMKjBMAcWT5KgF1nYCchN-Q%40mail.gmail.com.