typeshed
typeshed copied to clipboard
python
PEP 612 (Parameter Specification variables) tracker
This issue is supposed to track when we can start to use parameter specification variables (PEP 612) in typeshed. Support is needed in released versions of:
- [ ] mypy (python/mypy#8645)
- [x] basic
ParamSpecsupport - [x]
Concatenatesupport (python/mypy#11833) - [ ] Parameterising classes with
ParamSpec(python/mypy/issues/12011)
- [x] basic
- [x] pytype (google/pytype#786)
- [x] pyright (microsoft/pyright#654)
- [X] pyre
- [x] PyCharm (PY-49935)
@rchen152 Does pytype support PEP 612? If not, would you mind me creating a ticket that we can reference from here?
pytype does not yet support this. I opened https://github.com/google/pytype/issues/786.
Is there any update on this issue? Has anyone started to work on the support in mypy? Pytype?
I'm aware that full support for PEP 612 is not easy to implement, but perhaps some minimal support could be added that simply treats all ParamSpecs as Any? That would allow us to start using ParamSpec and Concatenate within typeshed without regressing the behavior for mypy users. This minimal support apparently was already implemented in pytype. It looks like @hauntsaninja made some progress on support in mypy in this PR, but there hasn't been any update in this tracking issue since Jan 2020.
Maybe we need to think about ways to support declarations that are conditioned on support for specific type checking features. Perhaps something like a _typing_features.pyi file that defines symbols like __PEP612__. Type checkers that support specific features could assume these symbols are True and use the type declarations that take advantage of these features. Type checkers that don't support the feature would assume False and fall back on alternate declarations that don't use these features.
I think work on mypy support has stalled.
Another, more forceful, approach could be that we simply start using them in typeshed (perhaps with a liberal sprinkling of type ignores). It would then be individual type checkers' responsibilities to add support for new features, and the ecosystem can move forward without having to wait for the slowest type checker to update itself. We could start doing this say six months or a year after a PEP has been accepted.
Could we just cheat and derive ParamSpec from Any in typing_extensions, until type checkers add support? That said, I'm also fine to just start using ParamSpec and use # type: ignore. Maybe we could have a draft PR that implements ParamSpec in a file where it's useful to judge the fallout?
But in general I agree that we should be more aggressive about adding features, so as not to hold more up-to-date type checkers back.
Maybe we could have a draft PR that implements ParamSpec in a file where it's useful to judge the fallout?
#5476
ParamSpec can now be used in argument and return type positions, although # type: ignore is necessary. It's still untested whether it works as part of a Generic class.
Yeap, though there are some issues and limitations in PyCharm ParamSpec support atm. I organized the known problems in this meta ticket PY-51766. Feel free to report anything I've missed.
I checkmarked pytype. While it doesn't support ParamSpec per se, it accepts it.
I think we can now use ParamSpec without limitations in typeshed.
There's still a mypy bug I'm waiting on: https://github.com/python/typeshed/issues/7689#issuecomment-1111721328. I'll add it to the tracker.
#12475 im mypy also seems to be a ParamSpec issue
Edit: realised a second too late that this was not the mypy repo
I think we can now use ParamSpec without limitations in typeshed.
There's still a mypy bug I'm waiting on: #7689 (comment). I'll add it to the tracker.
The mypy issue has now been closed!