French translation - Mispelling

Hi everyone, I am sorry if here is not the place, but I went to http://www.django-fr.org/, and was automatically redirected here ^^ I saw a spelling error in a menu, and I thought I could contact some french translators team or something? (It would be much easier to me to explain it in

Re: Fail test runs on unraisable exceptions?

Would we need to run “gc.collect” after each test to make it deterministic? I’m all for this change - I think it’s a sensible thing to do. Tom > On 30 Oct 2020, at 16:30, Adam Johnson wrote: > >  > -Werror transforms warnings into exceptions. This is what happens with the > asyncio case yes

Re: Fail test runs on unraisable exceptions?

-Werror transforms warnings into exceptions. This is what happens with the asyncio case yes - but the exception is unraisable so python prints the stack trace and carries on as if no problem occurred. Focussing only on the asyncio case may be counter productive. They are warnings by default and

Re: Fail test runs on unraisable exceptions?

> On 30 Oct 2020, at 14:20, Adam Johnson wrote: > > My proposal is to put this into the test runner for Django users OK, I misunderstood. Gotcha. > … I'm not sure if failing the test run would always make sense. Always no, for the reasons given. Always awaiting every coroutine can be

Re: Fail test runs on unraisable exceptions?

> You’re right that these can linger, but not with Mariusz on the case :) My proposal is to put this into the test runner for Django users rather than (only) Django’s own test suite. Sadly we can’t have Mariusz on every project. > These errors though are raised at process exit thought right?

Re: Fail test runs on unraisable exceptions?

> On 30 Oct 2020, at 13:56, Adam Johnson wrote: > > > I'd be making sure we cleaned that up before merge (or, can you filter > > those... — I guess you can 樂) > > In my experience I’d something doesn’t fail, it gets ignored. Few people read > the logs of passing test runs and most projects

Re: Fail test runs on unraisable exceptions?

> I'd be making sure we cleaned that up before merge (or, can you filter those... — I guess you can 樂) In my experience I’d something doesn’t fail, it gets ignored. Few people read the logs of passing test runs and most projects I’ve seen have a pile of noisy warnings making detecting unraisable

Re: Welcome email

The export finally finished after a whole day running. The gzip compressed mbox: https://www.icloud.com/iclouddrive/09XBHCr5L5BNcOBLob_HA2x6g The entire raw output from the tool:

Re: #28560 - distinct() on ordered queryset with restricted list of columns returns incorrect result

I misunderstood the bug, the blog post Fran linked to has cleared it up for me. I think option 3 makes sense now. On Thu, 29 Oct 2020 at 12:52, Michael Manfre wrote: > Having run in to this issue in the past, automatically changing the > meaning and/or breaking the query can turn in to a debug

Re: Fellow Reports - October 2020

Week ending October 25, 2020. *Triaged: * https://code.djangoproject.com/ticket/31922 - QuerySet.filter() against Q() with Subquery() and __in produces wrong results. (duplicate) https://code.djangoproject.com/ticket/32116 - QuerySet.order_by() crashes on combined queryset with a single