Replace asgiref for native types

[Kludex]

• Alternative to Remove asgiref from minimal requirements #1460
• Closes asgiref backward compatibility #1305

Questions

• Where should I add the asgiref copyright?

[adriangb]

First off thank you for all of these great PRs. I can tell you're putting a great deal of work into trying out all of the alternatives.

I like the idea of having our own types vs. #1460. Two questions:

1. Will this break integrations with other packages, e.g. a middleware that uses the asgiref types? Or will it still work as long as they are "equivalent"?
2. What do you think would be the pros/cons of having simpler types, like we have in Starlette? I think we're mainly using these internally within the codebase, so if it's just for us, do we need the more complex types to catch our mistakes, or would the simpler types be enough?

[Kludex]

Will this break integrations with other packages, e.g. a middleware that uses the asgiref types? Or will it still work as long as they are "equivalent"?

It will work as long as the types are equivalent.

from typing import Protocol, cast


class AsgirefType(Protocol):
    def __call__(self, a: int) -> None:
        ...


class UvicornType(Protocol):
    def __call__(self, a: int) -> None:
        ...


def uvicorn_code(callable: UvicornType) -> None:
    ...


def lamb(a: int) -> None:
    ...


asgiref_callable = cast(AsgirefType, lamb)
uvicorn_code(asgiref_callable)  # uvicorn_code expects UvicornType, but we are giving AsgirefType

The above works - no issues with mypy or pyright.

What do you think would be the pros/cons of having simpler types, like we have in Starlette? I think we're mainly using these internally within the codebase, so if it's just for us, do we need the more complex types to catch our mistakes, or would the simpler types be enough?

I can see a path from the less strict types to the more strict ones, but I don't see any reason to follow this now.

[Kludex]

• Let's discuss it first on What to do with `asgiref`? #1527