is it too late to consider trio? for class-based async views, can we get inspiration from django-vanilla-views? what about making new async views instead of current class based views?

@auvipy Unfortunately, while I like trio, it has a much smaller library ecosystem and so pragmatically we can't use it. My hope is eventually to make it possible to use in some situations.

Some more class-based views discussion is over on the forum (https://forum.djangoproject.com/c/internals/async) - while new async views is cleanest, it does mean having two versions of everything to maintain, which isn't great.

@aeros We use the iscoroutinefunction function from asyncio as it allows us to flag things that are effectively coroutine functions (i.e. callables that return a coroutine) that are not declared as async def. Specifically, this is used in our SyncToAsync wrapper that turns sync-callables into async-callables.

By my reading, the inspect version does not offer this, whereas the asyncio version lets you annotate functions with asyncio.coroutines._is_coroutine to mark them as such. Given this, we can't use the inspect version, as it's too narrow - it only returns functions that were declared async def, rather than actually telling you if something is a coroutine function.

By my reading, the inspect version does not offer this, whereas the asyncio version lets you annotate functions with asyncio.coroutines._is_coroutine to mark them as such. Given this, we can't use the inspect version, as it's too narrow - it only returns functions that were declared async def, rather than actually telling you if something is a coroutine function.

@andrewgodwin That's correct. I mainly wanted to make sure that it was intentional and it's clear that doing so will indirectly support the older generator coroutines that are being deprecated in Python 3.10 (unless asyncio.iscoroutine() and asyncio.iscoroutinefunction() are changed). I wasn't aware of Django's SyncToAsync wrapper, but I can see why inspect.iscoroutine() would not be compatible with it.

Given that this branch now passes all tests and shows no drop in sync performance in my testing, I consider it ready for review. I've also added relevant docs.

(I did not squash the commits down as I want to either do that with github's squash-and-merge, or wait until all requested changes are through and we're ready to go)

Good point about the testing - I always tend to forget that late in a project (especially as I was mostly performance-testing this with a separate suite). I'll try to get some extra tests in today or over the weekend and get that coverage up.

@carltongibson I've added more handler tests as well as the necessary AsyncClient we needed to support them, and then some user docs about using all this for your own async tests.

Super @andrewgodwin! I saw the commit come in and had to laugh. Great work. Will look again tomorrow.

@carltongibson Ah, interesting! I only ever run the test suites rather than the individual methods, so I never ran into this.

Let me go dive in and see if I can figure out a way to have Django do this automatically; I had considered making the test runner just auto-apply async_to_sync, so maybe this is the time to do this.

Hey @andrewgodwin Super. Thanks.

Whilst you're looking... My other (currently proto-) question is, Can we reduce the number of async defs in test/client.py?

• Does AsyncRequestFactory need async def at all?
  • If yes, can it just be request(), but that doesn't await anything so...?
• Then we just have async def request() in AsyncClient, which does await.

Am still playing with it, but thought I'd mention it early since you're here. 🙂

Other than that, this is looking good I think. (Time to ask @felixxm to get out the fine-toothed comb, before another fine read of the docs...) Thanks for the super effort.

@carltongibson I don't think I can stop AsyncRequestFactory.request being one - since its child AsyncClient.request is - but I might be able to remove it from AsyncRequestFactory.generic. Will have a go.

I think that's allowed:

import asyncio


class Parent:
    def foo(self):
        return "Hello"


class Child(Parent):
    async def foo(self):
        return super().foo()


async def main():
    c = Child()
    return await c.foo()


if __name__ == '__main__':
    print(
        asyncio.run(main())
    )

Runs as

~/Desktop $ python async_subclass.py 
Hello

Nothing seemed to break when I was experimenting earlier.

I see you rebased. Failures are from 4e8d6a1

@andrewgodwin In the last commit aff07dc527f9ae6b91c68ed741258fbd15d74045 I tried to use AsyncRequestFactory in asgi.tests. Can you take a look?

@carltongibson That fixup looks good to me - thanks for doing all the Sphinx linking that I often forget!

@felixxm That looks like a sensible change to me, nice way of reducing the scope duplication.

I moved documentation of async adapter functions to a separate PR #12562.

@andrewgodwin I think AsyncRequestFactory is missing in docs/topics/testing/advanced.txt 🤔 (django/test/client.py is the last file that I'm checking/polishing, so we're really close 🥇).

I push small changes:

• made AsyncClient and AsyncRequestFactory importable from django.test,
• added basic tests for HTTP methods of AsyncRequestFactory.

I added a small section about AsyncRequestFactory in the docs just now, too.

@andrewgodwin Can you take a look at our recent changes?

I just pushed 40ca60c10f09edc0a24acf756c8daf471f8b82de, which adds an:

await communicator.wait() 

... at the end of the FileResponse test case asgi.tests.ASGITest.test_file_response

Previously we had a:

Exception ignored in: <_io.FileIO name='.../django/tests/asgi/urls.py' mode='rb' closefd=True>
Traceback (most recent call last):
  File ".../3.9.0a4/lib/python3.9/asyncio/events.py", line 81, in _run
    self._context.run(self._callback, *self._args)
ResourceWarning: unclosed file <_io.BufferedReader name='...django/tests/asgi/urls.py'>

This was caused by the sync_to_async(response.close) future getting a asyncio.exceptions.CancelledError when the communcator went out of scope at the end of the test case.

We just need to make sure the app has a chance to finish in these cases.
(Noting for future. 🙂)

Yup, all these edits look good to me. Thanks to both of you!

Cheers @andrewgodwin. Thanks for the confirmation.

I think we're there 🤞. @felixxm can press the button. 😀

💃⛵️🎇

Thanks y'all 🥇 🚀 🎊

Thanks so much for all your hard work reviewing!

Now, let's take a look at that ORM... :)

@andrewgodwin 🤯!

Thank you for this!