You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In other words, it is a decorator that accepts the same shape of arguments as the wrapped function, and calls the wrapped function with them before returning the original function. (The exact reason for wanting this is a bit involved, but for example could be used to globally register trace-precompilation of some jitted functions).
Pyright (the type checker that pylance is based on) conforms to the Python typing spec. For details about how ParamSpec's work, please refer to this chapter.
What you are trying to do here isn't currently possible with the facilities in the typing spec.
If you'd like to propose new features for the Python type system, the process for amending or adding to the spec is documented here. A good starting place is to post to the Python typing forum with a description of the problem you're trying to solve plus (optionally) a proposed solution.
I don't see an obvious way to make ParamSpecs work in reverse like this, but maybe someone else on the forum will have some ideas.
This issue may be related to #4391 but I'm not sure.
I have a decorator that looks like this:
In other words, it is a decorator that accepts the same shape of arguments as the wrapped function, and calls the wrapped function with them before returning the original function. (The exact reason for wanting this is a bit involved, but for example could be used to globally register trace-precompilation of some jitted functions).
I can type this with a ParamSpec:
but this doesn't work:
This isn't surprising, because at the point of calling
my_decorator
, we don't yet know which function it is going to decorator.I wonder if pylance could support such a reverse-type-inference for decorators?
The text was updated successfully, but these errors were encountered: