Django possui suporte de desenvolvimento para o Python assíncrono(“async”), mas ainda não suporta views assíncronas ou middleware; eles virão em um lançamento futuro.
\nThere is limited support for other parts of the async ecosystem; namely, Django\ncan natively talk ASGI, and some async\nsafety support.
\nCertain key parts of Django are not able to operate safely in an asynchronous\nenvironment, as they have global state that is not coroutine-aware. These parts\nof Django are classified as “async-unsafe”, and are protected from execution in\nan asynchronous environment. The ORM is the main example, but there are other\nparts that are also protected in this way.
\nIf you try to run any of these parts from a thread where there is a running\nevent loop, you will get a\nSynchronousOnlyOperation error. Note that you\ndon’t have to be inside an async function directly to have this error occur. If\nyou have called a synchronous function directly from an asynchronous function\nwithout going through something like sync_to_async() or a threadpool,\nthen it can also occur, as your code is still running in an asynchronous\ncontext.
If you encounter this error, you should fix your code to not call the offending\ncode from an async context; instead, write your code that talks to async-unsafe\nin its own, synchronous function, and call that using\nasgiref.sync.sync_to_async(), or any other preferred way of running\nsynchronous code in its own thread.
If you are absolutely in dire need to run this code from an asynchronous\ncontext - for example, it is being forced on you by an external environment,\nand you are sure there is no chance of it being run concurrently (e.g. you are\nin a Jupyter notebook), then you can disable the warning with the\nDJANGO_ALLOW_ASYNC_UNSAFE environment variable.
Se você precisar de fazer isso dentro do Python, faça isso com os.environ:
os.environ["DJANGO_ALLOW_ASYNC_UNSAFE"] = "true"\nIt is necessary to adapt the calling style when calling synchronous code from\nan asynchronous context, or vice-versa. For this there are two adapter\nfunctions, made available from the asgiref.sync package:\nasync_to_sync() and sync_to_async(). They are used to transition\nbetween sync and async calling styles while preserving compatibility.
These adapter functions are widely used in Django. The asgiref package\nitself is part of the Django project, and it is automatically installed as a\ndependency when you install Django with pip.
async_to_sync()Link para este cabeçalho#Envolve uma função assíncrona e retorna uma função síncrona em seu lugar. Pode ser usado tanto como um invólucro direto ou um decorador:
\nfrom asgiref.sync import async_to_sync\n\nsync_function = async_to_sync(async_function)\n\n@async_to_sync\nasync def async_function(...):\n ...\nThe asynchronous function is run in the event loop for the current thread, if\none is present. If there is no current event loop, a new event loop is spun up\nspecifically for the async function and shut down again once it completes. In\neither situation, the async function will execute on a different thread to the\ncalling code.
\nThreadlocals e valores de contextvars são preservados através do limite em ambas as direções
\nasync_to_sync() is essentially a more powerful version of the\nasyncio.run() function available in Python’s standard library. As well\nas ensuring threadlocals work, it also enables the thread_sensitive mode of\nsync_to_async() when that wrapper is used below it.
sync_to_async()Link para este cabeçalho#Wraps a synchronous function and returns an asynchronous (awaitable) function\nin its place. Can be used as either a direct wrapper or a decorator:
\nfrom asgiref.sync import sync_to_async\n\nasync_function = sync_to_async(sync_function)\nasync_function = sync_to_async(sensitive_sync_function, thread_sensitive=True)\n\n@sync_to_async\ndef sync_function(...):\n ...\nThreadlocals e valores de contextvars são preservados através do limite em ambas as direções
\nFunções síncronas costumam ser escritas assumindo que todas rodam no thread principal, então sync_to_async() tem dois modos de thread
thread_sensitive=False ( o padrão): a função síncrona irá rodar em um novo thread que então é encerrado uma vez completo
thread_sensitive=True: the synchronous function will run in the same\nthread as all other thread_sensitive functions, and this will be the main\nthread, if the main thread is synchronous and you are using the\nasync_to_sync() wrapper.
Thread-sensitive mode is quite special, and does a lot of work to run all\nfunctions in the same thread. Note, though, that it relies on usage of\nasync_to_sync() above it in the stack to correctly run things on the\nmain thread. If you use asyncio.run() (or other options instead), it will\nfall back to just running thread-sensitive functions in a single, shared thread\n(but not the main thread).
The reason this is needed in Django is that many libraries, specifically\ndatabase adapters, require that they are accessed in the same thread that they\nwere created in, and a lot of existing Django code assumes it all runs in the\nsame thread (e.g. middleware adding things to a request for later use by a\nview).
\nRather than introduce potential compatibility issues with this code, we instead\nopted to add this mode so that all existing Django synchronous code runs in the\nsame thread and thus is fully compatible with asynchronous mode. Note, that\nsynchronous code will always be in a different thread to any async code that\nis calling it, so you should avoid passing raw database handles or other\nthread-sensitive references around in any new code you write.
\n