Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Question: how to use pyre_extensions.ParameterSpecification (PEP 612) #855

Closed
Congee opened this issue Jul 18, 2020 · 6 comments
Closed
Labels
as designed Not a bug, working as intended

Comments

@Congee
Copy link

Congee commented Jul 18, 2020

typing.ParameterSpecification is not available until 3.9. I'm trying to get it work with the library pyre_extensions which you seem to have covered here.

from typing import Any, List, Optional, Type, TypeVar
_T = TypeVar("_T")
def none_throws(optional: Optional[_T], message: str = ...) -> _T: ...
def safe_cast(new_type: Type[_T], value: Any) -> _T: ...
def ParameterSpecification(__name: str) -> List[Type[Any]]: ...

And it is tested here.

Ps = ParameterSpecification("Ps")

I don't understand why I get an error since you have already implementd PEP 612.
image

Did I miss anything?

I'm using coc-pyright with pyright 1.1.53

@erictraut
Copy link
Collaborator

Pyright doesn't know anything about pyre_extensions, which is specific to the pyre type checker. That explains why you're not seeing the behavior you're expecting.

I did add support for ParameterSpecification in Pyright in anticipation of this functionality being included in Python 3.9. Unfortunately, it appears that PEP 612 has not yet been ratified, which means it's unlikely to make it into Python 3.9 and will need to wait until 3.10. That's why it hasn't yet appeared in the official typing.pyi in typeshed.

The version of typing.pyi that currently ships with Pyright deviates slightly from the version that's checked into typeshed. It includes the following addition:

if sys.version_info >= (3, 9):
    class ParameterSpecification:
        args: Any = ...
        kwargs: Any = ...

        def __init__(self, name: str): ...

The version of typing.pyi that currently ships with Pylance does not contain this addition, since we're trying to stick with stock typehshed stubs for Pylance.

I will likely remove the above code in an upcoming version of Pyright now that it has become clear that PEP 612 won't make it into Python 3.9.

If you want to play with the ParameterSpecification support that's in Pyright today, you can hand-edit your typing.pyi file to include the above block. Just note that your modifications will get overwritten the next time Pyright or Pylance are updated.

@erictraut erictraut added the as designed Not a bug, working as intended label Jul 19, 2020
@Congee
Copy link
Author

Congee commented Jul 19, 2020

Thank you!

@layday
Copy link

layday commented Jul 19, 2020

Also note that the PEP was revised last month with the addition of Concatenate and with ParameterSpecification shortened to ParamSpec (python/peps#1424).

@charmoniumQ
Copy link

charmoniumQ commented Apr 15, 2021

Unfortunately, stubbing out ParamSpec doesn't work with Generic. It yields this error at runtime: TypeError: Parameters to generic types must be types.. (What happened to type annotations being ignored at runtime? Why does Generic explicitly check the type of its arguments at runtime?)

Unfortunately, I don't understand how metaclasses work in Python, so I can't figure out how to adapt your snippet to be a type. Inheriting from type says: TypeError: type.__new__() takes exactly 3 arguments (1 given).

Is there any backwards-compatible way to use ParamSpec?

Minimal (not) working example:

from typing import Generic, Any

class ParamSpec:
    def __init__(self, name: str): ...
    args: Any = ...
    kwargs: Any = ...

P = ParamSpec("P")
class CallP(Generic[P]):
    ...

@erictraut
Copy link
Collaborator

I can't tell what you're trying to do here. Perhaps you could post a more detailed question in the Discussions, and we'll try to help you out.

@charmoniumQ
Copy link

charmoniumQ commented Apr 15, 2021

For posterity's sake, the follow-up is here.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
as designed Not a bug, working as intended
Projects
None yet
Development

No branches or pull requests

4 participants