Re: Easy Pickings: support robust on_commit handlers

[Josh Smeaton]

Apologies for some reason I didn't get any replies to my inbox! If you'd 
like to tag me on any WIP PRs I'm willing to lend a hand and test.

On Thursday, 7 April 2022 at 22:19:44 UTC+10 revan...@almabase.com wrote:

>
> Hi Josh,
>
> I am also interested to work on this ticket. I am also aware of how can I 
> execute this. It would be great if I could contribute as I am eagerly 
> waiting to have my first contribution to Django. However, I would also be 
> happy to help anyone who is willing to contribute.
>
> Thanks,
> Revanth
> On Wednesday, April 6, 2022 at 11:08:04 PM UTC+5:30 omanir...@gmail.com 
> wrote:
>
>> Hi Josh, all 
>>
>> I am interested to work on this ticket, this would be my first time 
>> contributing. 
>> I have read and worked through the article "Writing your first patch for 
>> Django".   I should be fine with the getting started part. 
>>
>> I am looking for someone  reach out to personally to get my thoughts 
>> validated/ get help. 
>>
>> thanks
>> On Monday, 4 April, 2022 at 10:20:45 am UTC+5:30 josh.s...@gmail.com 
>> wrote:
>>
>>> I've just created a ticket for supporting robust on_commit handlers that 
>>> I think might be a good first ticket for somebody looking to get into 
>>> contributing to Django.
>>>
>>> https://code.djangoproject.com/ticket/33616
>>>
>>> I'd be more than happy to review any patch and provide guidance if 
>>> required. It's been quite a while since I've contributed directly so I may 
>>> not be too helpful in the "getting started" phase, but the existing 
>>> documentation would be a good place to begin 
>>> https://docs.djangoproject.com/en/dev/internals/contributing/writing-code/
>>>
>>

-- 
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/ee292903-3e00-4734-8594-ab08444dc336n%40googlegroups.com.

Re: Blocking disposable or temporary email addresses

['Tobias McNulty' via Django developers (Contributions to Django itself)]

Hi Yonas,

Thanks for sharing this list. Even so, in my opinion, this feature lives
best outside of Django where it can be appropriately customized as needed
for a given project.

I hope this helps.

Best,
Tobias


On Wed, May 11, 2022, 6:46 PM Yonas 
wrote:

>
> Would syncing the block list from repos like
> https://github.com/disposable-email-domains/disposable-email-domains
> (actively maintained since 2014) ease the burden of updating the list?
> On Thursday, May 12, 2022 at 12:44:28 AM UTC+3 James Bennett wrote:
>
>> On Wed, May 11, 2022 at 2:21 PM Yonas 
>> wrote:
>>
>>> What does the community think about adding a feature to Django where
>>> disposable or temporary emails are not accepted during account registration?
>>
>>
>> I used to try to do this in my django-registration package, but
>> eventually gave up on it because maintaining an up-to-date list of all
>> possible domains and other patterns was not feasible. I expect the same
>> would be true with Django — it would require frequent updates to the list
>> of domains/patterns to block, and people would complain that the updates
>> weren’t fast enough, because Django only releases once a month (and that’s
>> assuming updates to the blocked email list would be considered for
>> inclusion in the monthly bugfix releases, rather than only at feature
>> release updates).
>>
>> So I expect this isn’t something Django could or should do.
>>
> --
> 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/b669801b-f695-49c2-9d04-2ff7db74dc58n%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/CAMGFDKRONKrsAw35VBN8%3DYiNWkEzQWd5kUcYH1G8CjqG2eo%3DbQ%40mail.gmail.com.

Re: Blocking disposable or temporary email addresses

[Yonas]

Would syncing the block list from repos like 
https://github.com/disposable-email-domains/disposable-email-domains 
(actively maintained since 2014) ease the burden of updating the list?
On Thursday, May 12, 2022 at 12:44:28 AM UTC+3 James Bennett wrote:

> On Wed, May 11, 2022 at 2:21 PM Yonas  
> wrote:
>
>> What does the community think about adding a feature to Django where 
>> disposable or temporary emails are not accepted during account registration?
>
>
> I used to try to do this in my django-registration package, but eventually 
> gave up on it because maintaining an up-to-date list of all possible 
> domains and other patterns was not feasible. I expect the same would be 
> true with Django — it would require frequent updates to the list of 
> domains/patterns to block, and people would complain that the updates 
> weren’t fast enough, because Django only releases once a month (and that’s 
> assuming updates to the blocked email list would be considered for 
> inclusion in the monthly bugfix releases, rather than only at feature 
> release updates).
>
> So I expect this isn’t something Django could or should do.
>

-- 
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/b669801b-f695-49c2-9d04-2ff7db74dc58n%40googlegroups.com.

Re: Blocking disposable or temporary email addresses

[James Bennett]

On Wed, May 11, 2022 at 2:21 PM Yonas 
wrote:

> What does the community think about adding a feature to Django where
> disposable or temporary emails are not accepted during account registration?


I used to try to do this in my django-registration package, but eventually
gave up on it because maintaining an up-to-date list of all possible
domains and other patterns was not feasible. I expect the same would be
true with Django — it would require frequent updates to the list of
domains/patterns to block, and people would complain that the updates
weren’t fast enough, because Django only releases once a month (and that’s
assuming updates to the blocked email list would be considered for
inclusion in the monthly bugfix releases, rather than only at feature
release updates).

So I expect this isn’t something Django could or should do.

-- 
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/CAL13Cg8hgvUkoQyQJ9ryXY%2ByvuabAjonUY4VibXtzmWAYYtt7Q%40mail.gmail.com.

Re: Blocking disposable or temporary email addresses

[Dylan Reinhold]

You will never be able to define a "disposable or temporary" email address
or provider, so it's a non-starter from my perspective.

Dylan

On Wed, May 11, 2022 at 2:21 PM Yonas 
wrote:

> Hi,
>
> Hope everyone is doing well!
>
> What does the community think about adding a feature to Django where
> disposable or temporary emails are not accepted during account registration?
>
> Best,
> Yonas
>
> --
> 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/c6101816-f267-4568-88d8-5b8f17bfd92en%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/CAHtg44Dh8N7h8qsrNXebTs1CFEWpOGNhQU1Mqj-dF-cEzG3Byw%40mail.gmail.com.

Blocking disposable or temporary email addresses

[Yonas]

Hi,

Hope everyone is doing well!

What does the community think about adding a feature to Django where 
disposable or temporary emails are not accepted during account registration?

Best,
Yonas

-- 
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/c6101816-f267-4568-88d8-5b8f17bfd92en%40googlegroups.com.

Re: Equality check for two QuerySet

['Adam Johnson' via Django developers (Contributions to Django itself)]

I don't think there can be a performant way to compare two querysets.

Moreover, which features should be considered in equality would be very
complicated, when you consider the more involved parts of the API like
database functions, annotations, subqueries, etc.

One can check via the database if two queries give the same results with
the difference() method:
https://docs.djangoproject.com/en/4.0/ref/models/querysets/#django.db.models.query.QuerySet.difference
. For example:

querysets_the_same = not qs1.difference(qs2).exists()


On Wed, May 11, 2022 at 2:41 PM mohamad ali mehdizadeh 
wrote:

> Python `==` operator does not check references, it checks values, so qs2
> is a copy of qs1 but its value is the same so == must be True as it's not
> now.
> So I have a simple solution.
> def __eq__(self, other):
> if not isinstance(other, self.__class__):
> raise ValueError('Cannot compare a QuerySet to a non-QuerySet.')
> if not self.query.can_filter():
> return NotImplemented
> return not self.difference(other).union(other.difference(self)).exists()
>
> On Wednesday, May 11, 2022 at 12:14:51 AM UTC+4:30 ma...@wpsoft.at wrote:
>
>> I am not Agree.
>>
>> qs1.all() it is copy from qs1, the new object.
>>
>>
>>
>> I already try to write QuerySet compare on the Django 1.4 and i remember,
>>
>> that str(qs1.query) can be different as str(qs2.query), I am not Shure.
>>
>>
>>
>> Mit freundlichen Grüßen,
>>
>> DI Mag. Maxim Danilov
>>
>>
>>
>> +43(681)207 447 76
>>
>> ma...@wpsoft.at
>>
>>
>>
>> *From:* django-d...@googlegroups.com [mailto:django-d...@googlegroups.com]
>> *On Behalf Of *mohamad ali mehdizadeh
>> *Sent:* Tuesday, May 10, 2022 5:09 PM
>> *To:* Django developers (Contributions to Django itself) <
>> django-d...@googlegroups.com>
>> *Subject:* Equality check for two QuerySet
>>
>>
>>
>> Hi.
>> Why we don't have __eq__ for QuerySets, here is an example:
>> ```
>>
>> qs1 = Model.objects.all()
>>
>> qs2 = qs1.all()
>>
>> qs1 == qs2
>>
>> ```
>>
>> output: False
>>
>> as we know these two are the same by value!
>>
>> --
>> 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 view this discussion on the web visit
>> https://groups.google.com/d/msgid/django-developers/80e878f8-8701-40ad-92a0-5c689df27ec2n%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/a930c0e1-6cc9-4894-8922-a07aedad3fcdn%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/CAMyDDM2tir72pSEDoRUFLB%2Bof1tCcokEUZ%2BRED6U8GJQduqXVg%40mail.gmail.com.

Re: Performance does not scale when increasing file upload sizes

['Adam Johnson' via Django developers (Contributions to Django itself)]

Ferran - No, this is the right place. Noxx is suggesting a change to Django.

Noxx - it seems reasonable to improve Django here. You mentioned ASGI - did
you check what the WSGI paths do? It may be that the newer ASGI code is
simply less optimal.

Would it be possible to reduce the workflow to a single write call?
>

This is indeed the question. Could you investigate further and perhaps come
up with a patch? You're likely "the world expert" on this part of Django at
this point, after all the profiling you've done.


On Wed, May 11, 2022 at 5:44 PM Ferran Jovell  wrote:

> This is still the wrong place. Try django-users mailing list.
>
> El dc., 11 de maig 2022, 17:53, 'Noxx' via Django developers
> (Contributions to Django itself)  va
> escriure:
>
>> Story
>>
>> Our application supports many file uploads.
>> In normal circumstances, those files are only a few megabytes to of
>> around 100MB.
>> However, some uploads can be several GB in size (10-15GB and up).
>>
>> I know, that file uploads with such a size can be handled differently,
>> e.g. using a seperate endpoint, allowing slow requests to be served
>> seperately from the application etc.
>> and only to reference those files in a final request.
>> This solution would introduce some other problems regarding
>> house-keeping, non-atomic requests etc, thus I want to ignore this
>> workaround for now.
>> Performance impact:
>> 
>>
>> The impact can be best observed when uploading a file which is bigger in
>> it's size, e.g. 1GB+.
>> On my maschine it takes the client around 700ms to send the request to
>> the application, but than waits around 1.5s for the final response.
>> Of course, those numbers are dramatically influenced additionally in
>> production by storage speed, file size, webserver (uvicorn/daphne/..),
>> load-balancers etc.
>> But the final take here is, that the server does some additional work
>> after the client finished its request.
>> In a production-like environment the numbers peaks to 4s (send request)
>> and 16s (waiting for response) for the same file size. Uploading a 3GB
>> file, the numbers are 11s and 44s.
>> As you can see, the 44s are very near the default gateway timeout of
>> Nginx and the hard-coded one of AWS load-balancers.
>> As soon as the server needs more than 60s to create the response, the
>> client will get a gateway timeout error.
>> Workflow of file uploads:
>> 
>>
>> I'm not a Django-dev, so please correct me if I'm wrong. As far as I
>> understand, the uploaded file is processed as the following:
>>
>> Given, that the application is running within an ASGI server, the whole
>> request is received by the ASGIHandler.
>> It's method #read_body creates a SpooledTemporaryFile.
>> This temporary file contains the whole request body, including POST
>> parameters and files.
>>
>> As soon as the request has been received (this is the point the client
>> finished uploading the file) it is than transformed into an ASGIRequest.
>> The ASGIRequest has #_load_post_and_files and #parse_file_upload as
>> methods which parses the body into seperate files.
>> This is done by reading the body (the temporary file) and iterating over
>> them seperated by the POST seperator done by MultiPartParser.
>> The generated chunks are than sent to upload handlers which process those
>> files further on using #receive_data_chunk.
>> The default upload handlers provided by Django will write those files to
>> disc again, depending on their size.
>> Problem 
>>
>> The problem here is, that the uploaded file(s) are transformed and
>> written as well as read multiple times.
>> First the whole body is written into a SpooledTemporaryFile which is
>> re-read using streams (LazyStream) just to be written once more by an
>> upload handler.
>>
>> The impact is low if the uploaded file is small, but increases
>> dramatically if the size is increased, the file hits the disc and/or the
>> storage is slow.
>> Optimization / Brainstorming
>> 
>>
>> Would it be possible to reduce the workflow to a single write call?
>> E.g. if the ASGIHandler already splits the request body into seperate
>> files, it would be possible to just forward the file pointers until the
>> upload handlers needs to be called.
>> Those handlers would be able to either use those files as-is or to
>> re-read them if pre-processing is needed.
>>
>> In a best-case scenario, an user uploads a file whichis created as a
>> temporary file in parallel.
>> As soon as the request has been finished, the file is than moved to its
>> final location (as already implemented by upload handlers by providing
>> #temporary_file_path)
>> The server would not need any time processing the request further on and
>> would be able to sent the response within 

Re: Performance does not scale when increasing file upload sizes

[Ferran Jovell]

This is still the wrong place. Try django-users mailing list.

El dc., 11 de maig 2022, 17:53, 'Noxx' via Django developers (Contributions
to Django itself)  va escriure:

> Story
>
> Our application supports many file uploads.
> In normal circumstances, those files are only a few megabytes to of around
> 100MB.
> However, some uploads can be several GB in size (10-15GB and up).
>
> I know, that file uploads with such a size can be handled differently,
> e.g. using a seperate endpoint, allowing slow requests to be served
> seperately from the application etc.
> and only to reference those files in a final request.
> This solution would introduce some other problems regarding house-keeping,
> non-atomic requests etc, thus I want to ignore this workaround for now.
> Performance impact:
> 
>
> The impact can be best observed when uploading a file which is bigger in
> it's size, e.g. 1GB+.
> On my maschine it takes the client around 700ms to send the request to the
> application, but than waits around 1.5s for the final response.
> Of course, those numbers are dramatically influenced additionally in
> production by storage speed, file size, webserver (uvicorn/daphne/..),
> load-balancers etc.
> But the final take here is, that the server does some additional work
> after the client finished its request.
> In a production-like environment the numbers peaks to 4s (send request)
> and 16s (waiting for response) for the same file size. Uploading a 3GB
> file, the numbers are 11s and 44s.
> As you can see, the 44s are very near the default gateway timeout of Nginx
> and the hard-coded one of AWS load-balancers.
> As soon as the server needs more than 60s to create the response, the
> client will get a gateway timeout error.
> Workflow of file uploads:
> 
>
> I'm not a Django-dev, so please correct me if I'm wrong. As far as I
> understand, the uploaded file is processed as the following:
>
> Given, that the application is running within an ASGI server, the whole
> request is received by the ASGIHandler.
> It's method #read_body creates a SpooledTemporaryFile.
> This temporary file contains the whole request body, including POST
> parameters and files.
>
> As soon as the request has been received (this is the point the client
> finished uploading the file) it is than transformed into an ASGIRequest.
> The ASGIRequest has #_load_post_and_files and #parse_file_upload as
> methods which parses the body into seperate files.
> This is done by reading the body (the temporary file) and iterating over
> them seperated by the POST seperator done by MultiPartParser.
> The generated chunks are than sent to upload handlers which process those
> files further on using #receive_data_chunk.
> The default upload handlers provided by Django will write those files to
> disc again, depending on their size.
> Problem 
>
> The problem here is, that the uploaded file(s) are transformed and written
> as well as read multiple times.
> First the whole body is written into a SpooledTemporaryFile which is
> re-read using streams (LazyStream) just to be written once more by an
> upload handler.
>
> The impact is low if the uploaded file is small, but increases
> dramatically if the size is increased, the file hits the disc and/or the
> storage is slow.
> Optimization / Brainstorming
> 
>
> Would it be possible to reduce the workflow to a single write call?
> E.g. if the ASGIHandler already splits the request body into seperate
> files, it would be possible to just forward the file pointers until the
> upload handlers needs to be called.
> Those handlers would be able to either use those files as-is or to re-read
> them if pre-processing is needed.
>
> In a best-case scenario, an user uploads a file whichis created as a
> temporary file in parallel.
> As soon as the request has been finished, the file is than moved to its
> final location (as already implemented by upload handlers by providing
> #temporary_file_path)
> The server would not need any time processing the request further on and
> would be able to sent the response within some milliseconds independent of
> the file size.
> The roundtrip time would be reduced by 2/3 and also the gateway timeout
> would be fixed.
> Environment 
>
> We're using Django 4.0.4 with Gunicorn 20.1.0 and Uvicorn 0.17.6.
> Attachments 
>
> I've attached two flame graphs of a file upload which hopfully illustrates
> this issue.
> One is using the internal runserver (wsgi) and one of our (stripped)
> application using gunicorn+uvicorn (asgi)
>
> Final notes
>
> I'd by happy to get some thoughts and opinions on this issue and if this
> is even 

Performance does not scale when increasing file upload sizes

['Noxx' via Django developers (Contributions to Django itself)]

Story

Our application supports many file uploads.
In normal circumstances, those files are only a few megabytes to of around 
100MB.
However, some uploads can be several GB in size (10-15GB and up).

I know, that file uploads with such a size can be handled differently,
e.g. using a seperate endpoint, allowing slow requests to be served 
seperately from the application etc.
and only to reference those files in a final request.
This solution would introduce some other problems regarding house-keeping, 
non-atomic requests etc, thus I want to ignore this workaround for now.
Performance impact: 
 

The impact can be best observed when uploading a file which is bigger in 
it's size, e.g. 1GB+.
On my maschine it takes the client around 700ms to send the request to the 
application, but than waits around 1.5s for the final response.
Of course, those numbers are dramatically influenced additionally in 
production by storage speed, file size, webserver (uvicorn/daphne/..), 
load-balancers etc.
But the final take here is, that the server does some additional work after 
the client finished its request.
In a production-like environment the numbers peaks to 4s (send request) and 
16s (waiting for response) for the same file size. Uploading a 3GB file, 
the numbers are 11s and 44s.
As you can see, the 44s are very near the default gateway timeout of Nginx 
and the hard-coded one of AWS load-balancers.
As soon as the server needs more than 60s to create the response, the 
client will get a gateway timeout error.
Workflow of file uploads: 
 

I'm not a Django-dev, so please correct me if I'm wrong. As far as I 
understand, the uploaded file is processed as the following:

Given, that the application is running within an ASGI server, the whole 
request is received by the ASGIHandler.
It's method #read_body creates a SpooledTemporaryFile.
This temporary file contains the whole request body, including POST 
parameters and files.

As soon as the request has been received (this is the point the client 
finished uploading the file) it is than transformed into an ASGIRequest.
The ASGIRequest has #_load_post_and_files and #parse_file_upload as methods 
which parses the body into seperate files.
This is done by reading the body (the temporary file) and iterating over 
them seperated by the POST seperator done by MultiPartParser.
The generated chunks are than sent to upload handlers which process those 
files further on using #receive_data_chunk.
The default upload handlers provided by Django will write those files to 
disc again, depending on their size.
Problem  

The problem here is, that the uploaded file(s) are transformed and written 
as well as read multiple times.
First the whole body is written into a SpooledTemporaryFile which is 
re-read using streams (LazyStream) just to be written once more by an 
upload handler.

The impact is low if the uploaded file is small, but increases dramatically 
if the size is increased, the file hits the disc and/or the storage is slow.
Optimization / Brainstorming 
 

Would it be possible to reduce the workflow to a single write call?
E.g. if the ASGIHandler already splits the request body into seperate 
files, it would be possible to just forward the file pointers until the 
upload handlers needs to be called.
Those handlers would be able to either use those files as-is or to re-read 
them if pre-processing is needed.

In a best-case scenario, an user uploads a file whichis created as a 
temporary file in parallel.
As soon as the request has been finished, the file is than moved to its 
final location (as already implemented by upload handlers by providing 
#temporary_file_path)
The server would not need any time processing the request further on and 
would be able to sent the response within some milliseconds independent of 
the file size.
The roundtrip time would be reduced by 2/3 and also the gateway timeout 
would be fixed.
Environment  

We're using Django 4.0.4 with Gunicorn 20.1.0 and Uvicorn 0.17.6.
Attachments  

I've attached two flame graphs of a file upload which hopfully illustrates 
this issue.
One is using the internal runserver (wsgi) and one of our (stripped) 
application using gunicorn+uvicorn (asgi)

Final notes

I'd by happy to get some thoughts and opinions on this issue and if this is 
even possible to change/implement.

Cross-posted from https://code.djangoproject.com/ticket/33699 as ticket has 
been closed due to wrong place...

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group 

Re: Equality check for two QuerySet

[mohamad ali mehdizadeh]

Python `==` operator does not check references, it checks values, so qs2 is 
a copy of qs1 but its value is the same so == must be True as it's not now.
So I have a simple solution.
def __eq__(self, other):
if not isinstance(other, self.__class__):
raise ValueError('Cannot compare a QuerySet to a non-QuerySet.')
if not self.query.can_filter():
return NotImplemented
return not self.difference(other).union(other.difference(self)).exists()

On Wednesday, May 11, 2022 at 12:14:51 AM UTC+4:30 ma...@wpsoft.at wrote:

> I am not Agree.
>
> qs1.all() it is copy from qs1, the new object.
>
>  
>
> I already try to write QuerySet compare on the Django 1.4 and i remember, 
>
> that str(qs1.query) can be different as str(qs2.query), I am not Shure.
>
>  
>
> Mit freundlichen Grüßen,
>
> DI Mag. Maxim Danilov
>
>  
>
> +43(681)207 447 76
>
> ma...@wpsoft.at
>
>  
>
> *From:* django-d...@googlegroups.com [mailto:django-d...@googlegroups.com] 
> *On Behalf Of *mohamad ali mehdizadeh
> *Sent:* Tuesday, May 10, 2022 5:09 PM
> *To:* Django developers (Contributions to Django itself) <
> django-d...@googlegroups.com>
> *Subject:* Equality check for two QuerySet
>
>  
>
> Hi.
> Why we don't have __eq__ for QuerySets, here is an example:
> ```
>
> qs1 = Model.objects.all()
>
> qs2 = qs1.all()
>
> qs1 == qs2
>
> ```
>
> output: False
>
> as we know these two are the same by value!
>
> -- 
> 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 view this discussion on the web visit 
> https://groups.google.com/d/msgid/django-developers/80e878f8-8701-40ad-92a0-5c689df27ec2n%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/a930c0e1-6cc9-4894-8922-a07aedad3fcdn%40googlegroups.com.

Re: Status of 4.1 pre-release.

[Carlton Gibson]

On Wed, 11 May 2022 at 13:53, thinkwel...@gmail.com <
thinkwelldesi...@gmail.com> wrote:

> Will the psycopg3 backend 
> land in time for the 4.1 release?  I'm looking forward to it, as it should
> support PyPy much better than psycopg2 does.
>

No. It's not been worked on recently as far as I know. Next step would be
someone to pick the preliminary work up and push it forward. (A major
feature like that isn't something we'd add to the roster the week before
the feature freeze: we'd likely see it coming the whole release cycle.)

-- 
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/CAJwKpyT5ABcmuSHGbFBqeAcGO4U0McCTTq_%3DySkTa9Pvx4%3D1wQ%40mail.gmail.com.

Re: Status of 4.1 pre-release.

[thinkwel...@gmail.com]

Will the psycopg3 backend  
land in time for the 4.1 release?  I'm looking forward to it, as it should 
support PyPy much better than psycopg2 does.

On Wednesday, May 11, 2022 at 3:33:56 AM UTC-4 carlton...@gmail.com wrote:

> Hi Jacob. 
>
> I've always taken it that the person reviewing will do the marking. (I.e. 
> I don't read it as saying, "Find someone to review it and then mark it RFC 
> yourself", which would contradict the note in the FAQ yes.) 
>
> #32559 is on my list. IIRC it was there bar a few last tweaks, so I wanted 
> (want) to get it resolved. 
> C.
>
> On Wed, 11 May 2022 at 09:04, Jacob Rief  wrote:
>
>> Hi Carlton,
>> there is somehow a contradiction:
>> In https://code.djangoproject.com/wiki/Version4.1Roadmap it's written:
>>
>> Better yet, find someone to review your patch and mark the ticket as 
>>> "Ready for checkin".
>>>
>>
>> but 
>> https://docs.djangoproject.com/en/4.0/faq/contributing/#i-m-sure-my-ticket-is-absolutely-100-perfect-can-i-mark-it-as-ready-for-checkin-myself
>> states:
>>  
>>
>>> ’m sure my ticket is absolutely 100% perfect, can I mark it as “Ready 
>>> For Checkin” myself?
>>>
>>> Sorry, no. It’s always better to get another set of eyes on a ticket. If 
>>> you’re having trouble getting that second set of eyes, see questions above.
>>>
>>  
>> I'm actually asking, because of this I left one of my tickets 
>>  on "Accepted".
>>
>> Kind Regards,
>> Jacob
>>
>> -- 
>> 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 view this discussion on the web visit 
>> https://groups.google.com/d/msgid/django-developers/b4e386d5-b8be-4880-aa29-0c923c986518n%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/2b204160-31f2-46d2-9602-08a9445146e1n%40googlegroups.com.

Re: Status of 4.1 pre-release.

[Carlton Gibson]

Hi Jacob.

I've always taken it that the person reviewing will do the marking. (I.e. I
don't read it as saying, "Find someone to review it and then mark it RFC
yourself", which would contradict the note in the FAQ yes.)

#32559 is on my list. IIRC it was there bar a few last tweaks, so I wanted
(want) to get it resolved.
C.

On Wed, 11 May 2022 at 09:04, Jacob Rief  wrote:

> Hi Carlton,
> there is somehow a contradiction:
> In https://code.djangoproject.com/wiki/Version4.1Roadmap it's written:
>
> Better yet, find someone to review your patch and mark the ticket as
>> "Ready for checkin".
>>
>
> but
> https://docs.djangoproject.com/en/4.0/faq/contributing/#i-m-sure-my-ticket-is-absolutely-100-perfect-can-i-mark-it-as-ready-for-checkin-myself
> states:
>
>
>> ’m sure my ticket is absolutely 100% perfect, can I mark it as “Ready For
>> Checkin” myself?
>>
>> Sorry, no. It’s always better to get another set of eyes on a ticket. If
>> you’re having trouble getting that second set of eyes, see questions above.
>>
>
> I'm actually asking, because of this I left one of my tickets
>  on "Accepted".
>
> Kind Regards,
> Jacob
>
> --
> 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/b4e386d5-b8be-4880-aa29-0c923c986518n%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/CAJwKpyRhcYUPUsd47-N8Prrob%3DbjYo6fDVK%3DsHmVzEMuYk%3DOVA%40mail.gmail.com.

Re: Status of 4.1 pre-release.

[Mariusz Felisiak]

Yes, you shouldn't mark your patches as RFC.

*  "Better yet, find someone to review your patch and mark the ticket as 
"Ready for checkin".*

Was supposed to mean: *find someone who can review your patch and who will 
mark the ticket as RFC.*

Best,
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/8582b82d-8a64-4ac1-ad5f-ac7e8a169d47n%40googlegroups.com.

Re: Status of 4.1 pre-release.

[Jacob Rief]

Hi Carlton,
there is somehow a contradiction:
In https://code.djangoproject.com/wiki/Version4.1Roadmap it's written:

Better yet, find someone to review your patch and mark the ticket as "Ready 
> for checkin".
>

but 
https://docs.djangoproject.com/en/4.0/faq/contributing/#i-m-sure-my-ticket-is-absolutely-100-perfect-can-i-mark-it-as-ready-for-checkin-myself
states:
 

> ’m sure my ticket is absolutely 100% perfect, can I mark it as “Ready For 
> Checkin” myself?
>
> Sorry, no. It’s always better to get another set of eyes on a ticket. If 
> you’re having trouble getting that second set of eyes, see questions above.
>
 
I'm actually asking, because of this I left one of my tickets 
 on "Accepted".

Kind Regards,
Jacob

-- 
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/b4e386d5-b8be-4880-aa29-0c923c986518n%40googlegroups.com.