Skip to content

Question about the representation of ParamSpec Generic classes #1274

Closed
@Gobot1234

Description

@Gobot1234

While working on PEP 696 (TypeVarLike defaults) one point I've been particularly confused about how was the types that should be used for Generics with ParamSpecs in __parameters__ subscription.

Should you pass a list to the list as suggested in the PEP, types.GenericAlias and by mypy

class X(Generic[P]): ...

# from pep 612
def f(x: X[[int, bool]]) -> str: ...
reveal_type(X[[int, bool]]())  # mypy: revealed type is __main__.X[[builtins.int, builtins.bool]]

# using types.GenericAlias
class X_types:
    __class_getitem__ = classmethod(types.GenericAlias)
reveal_type(X_types[[int, bool]])  # runtime: X_types[[<class 'int'>, <class 'bool'>]]
reveal_type(X_types[(int, bool)])  # runtime: X_types[<class 'int'>, <class 'bool'>]

or use a tuple as the typing runtime suggests and by pyright

reveal_type(X[[int, bool]])  # runtime: revealed type is X[(<class 'int'>, <class 'bool'>)]
reveal_type(X[[int, bool]])  # pyright: revealed type is type[X[(int, bool)]]

This may seem relatively inconsequential and at runtime it probably is but after talking to @erictraut he brought up that PEP 696 supports both lists and tuples as the defaults for ParamSpec (https://peps.python.org/pep-0696/#paramspec-defaults) and this will be harder to support in pyright but I'd really like symmetry with the type of default and the type that you should pass to a subscription. Ideally I think I tuples would be the best type for for default just cause they should be the easiest to analyse and they are the closest in style to a PEP 677 (Callable Type Syntax) syntax even if the current syntax does look more like Callable's current syntax. Does anyone from the pyre team or from mypy have any particular opposition to changing to just supporting tuples in default?

Metadata

Metadata

Assignees

No one assigned

    Labels

    topic: otherOther topics not covered

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions