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
{{ message }}
Repository navigation
functools.partial should use PEP612 ParamSpec (depends on #8708) #8703
Currently, functools.partial's __call__ method takes *args: Any, **kwargs: Any and returns _T (a TypeVar for the return type of the callable the partial is wrapping). This is decent, but matching the parameter typing would make this more useful in more situations.
I can sort of see how to deal with this, although I'll admit I'm unsure how to make this generically work. I imagine you could probably deal with some number of Concatenates (maybe up to 5 or 10) to deal with most cases. It's possible fixing this requires another PEP to allow an arbitrary-length Concatenate-type pattern.
changed the title [-]functools.partial should use PEP612 ParamSpec[/-][+]functools.partial should use PEP612 ParamSpec (depends on #8708)[/+]on Sep 28, 2022
#8708 has been closed. Can this be un-deferred yet?
No, pytype still crashes (meaning our CI would fail) if we make a class Generic over a TypeVarTuple, which is what the solution outlined in #8703 (comment) would require.
@AlexWaygood
It would certainly be fantastic if the type annotations for partial captured something about the arguments as well the return type. But are you sure that the approach you outlined above would work, in principle? I didn't think it would be legal to unnpack a TypeVarTuple within Concatenate? I'm not sure if this is just a matter of the checkers not yet implementing it, or if there is some fundamental reason that this could not work, but currently both pyright and mypy disallow this.
Activity
AlexWaygood commentedon Sep 7, 2022
You can nearly get there with a combination of PEP 612 and PEP 646:
Mypy doesn't support PEP 646 yet, however. And even if it did, there would still be some corner cases that don't work (PyCQA/flake8-pyi#150 (comment))
benbariteau commentedon Sep 8, 2022
Hmmm, I think that's probably the best we're gonna get for now. It's a strict improvement in my opinion.
srittau commentedon Sep 8, 2022
Cf. #8708
[-]functools.partial should use PEP612 ParamSpec[/-][+]functools.partial should use PEP612 ParamSpec (depends on #8708)[/+]andersk commentedon Dec 11, 2023
#8708 has been closed. Can this be un-deferred yet?
AlexWaygood commentedon Dec 11, 2023
No, pytype still crashes (meaning our CI would fail) if we make a class Generic over a TypeVarTuple, which is what the solution outlined in #8703 (comment) would require.
Dreamsorcerer commentedon Dec 11, 2023
Is that the one that has apparently been fixed a couple of days ago: google/pytype#1525 (comment)
Or is there another issue to track?
AlexWaygood commentedon Dec 11, 2023
no
erikkemperman commentedon Jul 18, 2024
@AlexWaygood
It would certainly be fantastic if the type annotations for partial captured something about the arguments as well the return type. But are you sure that the approach you outlined above would work, in principle? I didn't think it would be legal to unnpack a
TypeVarTuplewithinConcatenate? I'm not sure if this is just a matter of the checkers not yet implementing it, or if there is some fundamental reason that this could not work, but currently both pyright and mypy disallow this.