8000 typing: Use PEP 695 syntax in typing.py by JelleZijlstra · Pull Request #104553 · python/cpython · GitHub
[go: up one dir, main page]
Skip to content

typing: Use PEP 695 syntax in typing.py #104553

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.

Sign up for GitHub

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

Merged
merged 5 commits into from
May 17, 2023
Merged

typing: Use PEP 695 syntax in typing.py #104553

Changes from 1 commit
Commits
Show all changes
5 commits
Select commit Hold shift + click to select a range
e1ff413
typing: Use PEP 695 syntax in typing.py
JelleZijlstra May 16, 2023
16b0978
Use an alias, remove unnecessary _co suffix
JelleZijlstra May 16, 2023
655d6ac
Merge branch 'main' into use695
AlexWaygood May 16, 2023
754dda0
Better type for dataclass_transform
JelleZijlstra May 17, 2023
302f071
Merge remote-tracking branch 'upstream/main' into use695
JelleZijlstra May 17, 2023
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
Next Next commit
typing: Use PEP 695 syntax in typing.py
  • Loading branch information
@JelleZijlstra
JelleZijlstra committed May 16, 2023
commit e1ff41381def68b4a13d61958e14cf85b71e4597
18 changes: 8 additions & 10 deletions Lib/typing.py
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -2471,8 +2471,9 @@ class Other(Leaf): # Error reported by type checker
return f


# Some unconstrained type variables. These are used by the container types.
# (These are not for export.)
# Some unconstrained type variables. These were initially used by the container types.
# They were never meant for export and are now unused, but we keep them around to
# avoid breaking compatibility with users who import them.
T = TypeVar('T') # Any type.
KT = TypeVar('KT') # Key type.
VT = TypeVar('VT') # Value type.
Expand Down Expand Up @@ -2577,8 +2578,6 @@ def new_user(user_class: Type[U]) -> U:
At this point the type checker knows that joe has type BasicUser.
"""

# Internal type variable for callables. Not for export.
F = TypeVar("F", bound=Callable[..., Any])
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This one was added as part of implementing override earlier in 3.12, so there's no need to keep it around for compatibility.


@runtime_checkable
class SupportsInt(Protocol):
Expand Down Expand Up @@ -2631,7 +2630,7 @@ def __index__(self) -> int:


@runtime_checkable
class SupportsAbs(Protocol[T_co]):
class SupportsAbs[T_co](Protocol):
"""An ABC with one abstract method __abs__ that is covariant in its return type."""
__slots__ = ()

Expand All @@ -2641,7 +2640,7 @@ def __abs__(self) -> T_co:


@runtime_checkable
class SupportsRound(Protocol[T_co]):
class SupportsRound[T_co](Protocol):
"""An ABC with one abstract method __round__ that is covariant in its return type."""
__slots__ = ()

Expand Down Expand Up @@ -3183,7 +3182,7 @@ class re(metaclass=_DeprecatedType):
sys.modules[re.__name__] = re


def reveal_type(obj: T, /) -> T:
def reveal_type[T](obj: T, /) -> T:
"""Reveal the inferred type of a variable.

When a static type checker encounters a call to ``reveal_type()``,
Expand All @@ -3203,7 +3202,7 @@ def reveal_type(obj: T, /) -> T:
return obj


def dataclass_transform(
def dataclass_transform[T](
8000 Copy link
Member
@AlexWaygood AlexWaygood May 16, 2023 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This feels slightly strange to me, as (to me) it implies that dataclass_transform is a function generic around the type variable T. But that's not really true; it's a non-generic function that returns an identity function. I skimmed PEP 695, and it doesn't seem to mention how such cases should be handled.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

IIRC we did think about this and decided that this is indeed how such cases should be spelled (since Callable doesn't have a way yet to spell "generic").

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think we shouldn't do this since it confuses scoping and much of the point of PEP 695 is to clarify scoping. We can use a callback protocol to spell this.

I'd brought this up somewhere before PEP 695 was accepted, but didn't get much of a response. Presumably since it's not the most common thing and I think e.g. pyre might not even support -> Callable[[T], T]

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Changed to a callback protocol

*,
eq_default: bool = True,
order_default: bool = False,
Expand Down Expand Up @@ -3288,8 +3287,7 @@ def decorator(cls_or_fn):
return decorator



def override(method: F, /) -> F:
def override[F: Callable[..., Any]](method: F, /) -> F:
"""Indicate that a method is intended to override a method in a base class.

Usage:
Expand Down
0