Re: Easy Pickings: support robust on_commit handlers

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 h

Re: Blocking disposable or temporary email addresses

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 r

Re: Blocking disposable or temporary email addresses

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

Re: Blocking disposable or temporary email addresses

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 mai

Re: Blocking disposable or temporary email addresses

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 >

Blocking disposable or temporary email addresses

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 (Con

Re: Equality check for two QuerySet

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

Re: Performance does not scale when increasing file upload sizes

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 si

Re: Performance does not scale when increasing file upload sizes

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 a

Performance does not scale when increasing file upload sizes

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 endpo

Re: Equality check for two QuerySet

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 n

Re: Status of 4.1 pre-release.

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

Re: Status of 4.1 pre-release.

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

Re: Status of 4.1 pre-release.

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 (wa

Re: Status of 4.1 pre-release.

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 y

Re: Status of 4.1 pre-release.

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-ab