The signature of the .dispatch method we add to decorated functions is *args, **kwargs, which says nothing about the types of arguments expected to be received. We know the arguments should be the same as those of the decorated function, but a type checker doesn't.
PEP-0612 introduces the ParamSpec concept, allowing us to express arbitrary function signatures as type annotations.
Maintaining type information is critical to leverage the type-checking capabilities of tools like mypy and Python IDEs. Without it, we create a fertile ground for developers to introduce errors that would prevent them from leveraging Dispatch.
As part of this change, we may have to abandon #43, because ParamSpec was introduced in Python 3.10.
Other challenges may get in the way of addressing this issue:
The dynamic detection we do to support paren-less decorators may also be challenging (e.g., dispatch.function instead of dispatch.function()) because we add an extra indirection layer to handle multiple signatures.
The dispatch.function.Function type is used as return type when decorating regular functions and coroutines (def and async def). At this stage, whether we can express return values from sync and async functions with the same syntax in the type annotation system is unclear to me.
Strong type checking is much more important than leaner APIs, so if we have to sacrifice some of the syntactic simplicity we have today to acquire stronger type checks, we should do it. If it turns out that we have to introduce breaking changes, let's relabel this issue as such.
The signature of the
.dispatchmethod we add to decorated functions is*args, **kwargs, which says nothing about the types of arguments expected to be received. We know the arguments should be the same as those of the decorated function, but a type checker doesn't.PEP-0612 introduces the
ParamSpecconcept, allowing us to express arbitrary function signatures as type annotations.Maintaining type information is critical to leverage the type-checking capabilities of tools like mypy and Python IDEs. Without it, we create a fertile ground for developers to introduce errors that would prevent them from leveraging Dispatch.
As part of this change, we may have to abandon #43, because
ParamSpecwas introduced in Python 3.10.Other challenges may get in the way of addressing this issue:
The dynamic detection we do to support paren-less decorators may also be challenging (e.g.,
dispatch.functioninstead ofdispatch.function()) because we add an extra indirection layer to handle multiple signatures.The
dispatch.function.Functiontype is used as return type when decorating regular functions and coroutines (defandasync def). At this stage, whether we can express return values from sync and async functions with the same syntax in the type annotation system is unclear to me.Strong type checking is much more important than leaner APIs, so if we have to sacrifice some of the syntactic simplicity we have today to acquire stronger type checks, we should do it. If it turns out that we have to introduce breaking changes, let's relabel this issue as such.