On Wed, Dec 22, 2021 at 7:13 AM Steven Troxler <steven.troxler@gmail.com> wrote:
Pradeep, Guido and I are leaning toward removing the `async` part of PEP 677.
There are several reasons: - If we leave `async` in, then `async (int) -> bool` and `(int) -> Awaitable[bool]` are the same - This violates that there should only be one obvious way to do things - It also might lead to a mismatch between written types and the errors returned by type checkers, leading to unnecessary confusion - It looks like < 5% of callable types return Awaitable anyway - It has explicitly been brought up in python-dev as unnecessary complexity, and we largely agree with this criticism.
For sync programs, it doesn't matter what we do, because they'll never write `async` or `Awaitable`. For async programs, having to put `Awaitable` everywhere adds a lot of visual noise. Most Python programs are sync, so any async-related syntax is necessarily going to be rare in absolute terms, but that's not really the relevant audience to think about. For modern code, `Awaitable` isn't used at definition point: you just write `async def foo(a: int) -> bool`. So keeping it in PEP 677 would make definition syntax and callable type syntax more consistent. I think it's a big win for usability. I also don't think it violates "one obvious way" -- emphasis on "obvious" :-). With PEP 677 as currently written, using `async` everywhere is the "obvious" way; `Awaitable` becomes a detail that only type nerds have to think about. -n -- Nathaniel J. Smith -- https://vorpus.org