# Buildsheet autogenerated by ravenadm tool -- Do not edit.

NAMEBASE=		python-asgiref
VERSION=		3.8.1
KEYWORDS=		python
VARIANTS=		v12 v13
SDESC[v12]=		ASGI specs, helper code, and adapters (3.12)
SDESC[v13]=		ASGI specs, helper code, and adapters (3.13)
HOMEPAGE=		https://github.com/django/asgiref/
CONTACT=		Python_Automaton[python@ironwolf.systems]

DOWNLOAD_GROUPS=	main
SITES[main]=		PYPIWHL/39/e3/893e8757be2612e6c266d9bb58ad2e3651524b5b40cf56761e985a28b13e
DISTFILE[1]=		asgiref-3.8.1-py3-none-any.whl:main
DF_INDEX=		1
SPKGS[v12]=		single
SPKGS[v13]=		single

OPTIONS_AVAILABLE=	PY312 PY313
OPTIONS_STANDARD=	none
VOPTS[v12]=		PY312=ON PY313=OFF
VOPTS[v13]=		PY312=OFF PY313=ON

DISTNAME=		asgiref-3.8.1.dist-info

GENERATED=		yes

[PY312].USES_ON=			python:v12,wheel

[PY313].USES_ON=			python:v13,wheel

[FILE:3473:descriptions/desc.single]
asgiref
=======

ASGI is a standard for Python asynchronous web apps and servers to
communicate
with each other, and positioned as an asynchronous successor to WSGI. You
can
read more at https://asgi.readthedocs.io/en/latest/

This package includes ASGI base libraries, such as:

* Sync-to-async and async-to-sync function wrappers, ``asgiref.sync``
* Server base classes, ``asgiref.server``
* A WSGI-to-ASGI adapter, in ``asgiref.wsgi``

Function wrappers
-----------------

These allow you to wrap or decorate async or sync functions to call them
from
the other style (so you can call async functions from a synchronous thread,
or vice-versa).

In particular:

* AsyncToSync lets a synchronous subthread stop and wait while the async
  function is called on the main thread's event loop, and then control is
  returned to the thread when the async function is finished.

* SyncToAsync lets async code call a synchronous function, which is run in
  a threadpool and control returned to the async coroutine when the
synchronous
  function completes.

The idea is to make it easier to call synchronous APIs from async code and
asynchronous APIs from synchronous code so it's easier to transition code
from
one style to the other. In the case of Channels, we wrap the (synchronous)
Django view system with SyncToAsync to allow it to run inside the
(asynchronous)
ASGI server.

Note that exactly what threads things run in is very specific, and aimed to
keep maximum compatibility with old synchronous code. See
"Synchronous code & Threads" below for a full explanation. By default,
sync_to_async will run all synchronous code in the program in the same
thread for safety reasons; you can disable this for more performance with
``@sync_to_async(thread_sensitive=False)``, but make sure that your code
does
not rely on anything bound to threads (like database connections) when you
do.

Threadlocal replacement
-----------------------

This is a drop-in replacement for ``threading.local`` that works with both
threads and asyncio Tasks. Even better, it will proxy values through from a
task-local context to a thread-local context when you use sync_to_async
to run things in a threadpool, and vice-versa for async_to_sync.

If you instead want true thread- and task-safety, you can set
thread_critical on the Local object to ensure this instead.

Server base classes
-------------------

Includes a StatelessServer class which provides all the hard work of
writing a stateless server (as in, does not handle direct incoming sockets
but instead consumes external streams or sockets to work out what is
happening).

An example of such a server would be a chatbot server that connects out to
a central chat server and provides a "connection scope" per user chatting
to
it. There's only one actual connection, but the server has to separate
things
into several scopes for easier writing of the code.

You can see an example of this being used in [frequensgi].

WSGI-to-ASGI adapter
--------------------

Allows you to wrap a WSGI application so it appears as a valid ASGI
application.

Simply wrap it around your WSGI application like so::

    asgi_application = WsgiToAsgi(wsgi_application)

The WSGI application will be run in a synchronous threadpool, and the
wrapped
ASGI application will be one that accepts http class messages.

Please note that not all extended features of WSGI may be supported (such
as
file handles for incoming POST bodies).

Dependencies
------------


[FILE:109:distinfo]
3e1e3ecc849832fe52ccf2cb6686b7a55f82bb1d6aee72a58826471390335e47        23828 asgiref-3.8.1-py3-none-any.whl