Mailman 3 February 2022 - Typing-sig

Opened and changed typing issues week 2022-W05
by Typing Bot 07 Feb '22

07 Feb '22

The following is an overview of all issues and pull requests in the typing repository on GitHub with the label 'topic: feature' that were opened or updated last week, excluding closed issues. --------------------------------------------------- The following issues and pull requests were updated last week: #920 Consider loosening restrictions of `Final` opened by @DetachHead https://github.com/python/typing/issues/920 #1043 TypingError: type checker will emit error with a message specified in typing stubs opened by @Akuli https://github.com/python/typing/issues/1043 --------------------------------------------------- All issues and pull requests with the label 'topic: feature' can be viewed under the following URL: https://github.com/python/typing/issues?q=label%3A%22topic%3A+feature%22

1 0

Proposal: typing.reveal_locals()
by Jelle Zijlstra 06 Feb '22

06 Feb '22

In the previous thread about reveal_type(), several people proposed also adding `typing.reveal_locals()`. In this thread I'd like to iron out any details and make sure we're all in agreement. # Specification We will add a new function `typing.reveal_locals()` with the following signature: def reveal_locals() -> None: ... At runtime, this function will do nothing. When a type checker encounters a call to reveal_locals(), it will emit the types of all variables in the local scope. For example: def f() -> None: a = 1 b = "x" reveal_locals() When typechecked, this may produce: Revealed local types are: a: builtins.int b: builtins.str # Motivation `reveal_locals()` is already implemented in mypy ( https://mypy.readthedocs.io/en/stable/common_issues.html#displaying-the-typ…) and pyright (undocumented). It is not as commonly used as reveal_type(), but can be useful for debugging type checker behavior. # Open questions What should the runtime behavior be? We could do something like sys._getframe(1).f_locals to get the calling function's locals and print them, but that isn't code I'd like to write.

7 17

StrictTypeGuard and TypeAssert
by Eric Traut 05 Feb '22

05 Feb '22

In a previous typing-sig thread (https://mail.python.org/archives/list/typing-sig@python.org/thread/EMUD2D42…) there was a discussion about the existing TypeGuard (PEP 647) and the desire to support a form that allows for type narrowing in the negative case. I previously proposed extending the existing TypeGuard to support an optional second type argument that represents the negative type. This proposal received lukewarm reception because it didn't address some desired use cases. Based on this feedback, I proposed a new idea in the python/typing discussion forum (https://github.com/python/typing/discussions/1013#discussioncomment-1966238). This new proposal introduces a form called "StrictTypeGuard". It also describes variants called "TypeAssert" and "StrictTypeAssert". I haven't received much feedback in that forum thread, so I figured I'd repost here. -- Taking in all of the feedback, here's an alternative proposal that involves the introduction of another form of TypeGuard which has "strict" type narrowing semantics. It would be less flexible than the existing TypeGuard, but the added constraints would allow it to be used for these alternate use cases. *StrictTypeGuard* This proposal would introduce a new flavor of TypeGuard that would have strict narrowing semantics. We'd need to come up with a new name for this, perhaps StrictTypeGuard, ExactTypeGuard, or PreciseTypeGuard. Other suggestions are welcome. For now, I'll refer to it as StrictTypeGuard. This new flavor of type guard would be similar to the more flexible version defined in PEP 647 with the following three differences: The type checker would enforce the requirement that the type guard type (specified as a return type of the type guard function) is a subtype of the input type (the declared type of the first parameter to the type guard function). In other words, the type guard type must be strictly narrower than the input type. This precludes some of the use cases anticipated in the original PEP 647. ```python def is_marsupial(val: Animal) -> StrictTypeGuard[Kangaroo | Koala]: # This is allowed return isinstance(val, Kangaroo | Koala) def has_no_nones(val: list[T | None]) -> StrictTypeGuard[list[T]]: # Error: "list[T]" cannot be assigned to "list[T | None]" return None not in val ``` Type narrowing would be applied in the negative ("else") case. This may still lead to incorrect assumptions, but it's less likely to be incorrect with restriction 1 in place. Consider, for example, ```python def is_black_cat(val: Animal) -> StrictTypeGuard[Cat]: return isinstance(val, Cat) and val.color == Color.Black def func(val: Cat | Dog): if is_black_cat(val): reveal_type(val) # Cat else: reveal_type(val) # Dog - which is potentially wrong here ``` If the return type of the type guard function includes a union, the type checker would apply additional type narrowing based on the type of the argument passed to the type guard call, eliminating union elements that are impossible given the argument type. For example: ```python def is_cardinal_direction(val: str) -> StrictTypeGuard[Literal["N", "S", "E", "W"]]: return val in ("N", "S", "E", "W") def func(direction: Literal["NW", "E"]): if is_cardinal_direction(direction): reveal_type(direction) # Literal["E"] # The type cannot be "N", "S" or "W" here because of argument type else: reveal_type(direction) # Literal["NW"] ``` * TypeAssert and StrictTypeAssert* As mentioned above, there has also been a desire to support a "type assert" function. This is similar to a "type guard" function except that it raises an exception (similar to an assert statement, except that its behavior is not dependent on 'debug' mode) if the input's type doesn't match the declared return type. This is analogous to "type predicate functions" supported in TypeScript, like the following: ```typescript function assertAuthenticated(user: User | null): asserts user is User { if (user === null) { throw new Error('Unauthenticated'); } } ``` We propose to add two new forms TypeAssert and StrictTypeAssert, which would be analogous to TypeGuard and StrictTypeGuard. While type guard functions are expected to return a bool value, "type assert" forms would return None (if the input type matches) or raise an exception (if the input type doesn't match). Type narrowing in the negative ("else") case doesn't apply for type assertions because it is assumed that an exception is raised in this event. Here are some examples: ```python def verify_no_nones(val: list[None | T]) -> TypeAssert[list[T]]: if None in val: raise ValueError() def func(x: list[int | None]): verify_no_nones(x) reveal_type(x) # list[int] and def assert_is_one_dimensional(val: tuple[T, ...] | T) -> StrictTypeAssert[tuple[T] | T]: if isinstance(val, tuple) and len(val) != 1: raise ValueError() def func(x: float, y: tuple[float, ...]): assert_is_one_dimensional(x) reveal_type(x) # float assert_is_one_dimensional(y) reveal_type(y) # tuple[float] ``` Thoughts? Suggestions? If we move forward with the above proposal (or some subset thereof), it will probably require a new PEP, as opposed to a modification to PEP 647. - Eric -- Eric Traut Contributor to Pyright & Pylance Microsoft

4 5

RFC on Arbitrary Literal Strings PEP
by S Pradeep Kumar 03 Feb '22

03 Feb '22

Hello all, We've drafted a PEP to support arbitrary literal string types [1]. Feedback appreciated! Scala has a very similar concept. See this talk on using Scala's literal string types for "Preventing SQL injection at compile time" [2] Bikeshedding: We're open to any name that seems easy to understand :) -- Best, S Pradeep Kumar Graham Bleaney [1]: https://docs.google.com/document/d/1fbAbA2MCoAcSO1c8gecmUJYZ-Q0utT3CmaXlQ3I… [2]: https://slideslive.com/38907881/literal-types-what-they-are-good-for (slides 52 to 68) [3]: Previous typing-sig thread: https://mail.python.org/archives/list/typing-sig@python.org/thread/JJWAA5AH…

14 24

Adding `typing.reveal_type`
by Jelle Zijlstra 02 Feb '22

02 Feb '22

I just opened https://bugs.python.org/issue46414 to propose adding `typing.reveal_type` to Python 3.11. Copying my message there: --- The `reveal_type()` primitive is injected by type checkers into the builtins. When the type checker sees a call, it prints the inferred type of the argument. This has been implemented across all type checkers, but adding an implementation to `typing` would help document the behavior and make it more discoverable for users. Also, it means code with `reveal_type()` calls can run without runtime errors, useful if you want to run your tests at the same time as you're debugging a typing issue. The runtime implementation can be very simple: def reveal_type(obj: _T, /) -> _T: print("Runtime type is", type(obj)) return obj reveal_type() is supported by all type checkers that I'm aware of (docs include https://google.github.io/pytype/faq.html#can-i-find-out-what-pytype-thinks-… for pytype and https://mypy.readthedocs.io/en/stable/common_issues.html#reveal-type for mypy). One area of divergence is the return value. Pyright returns the inferred type of the expression as a string (and uses that in its test suite for testing type inference). Mypy returns the argument, which has the advantage that you can insert `reveal_type()` in the middle of an expression without having to put it on its own line. Also, the Pyright behavior cannot sensibly be implemented at runtime. Therefore, I suggest using Mypy's behavior for `typing.reveal_type`. ---- I'm hoping this will be simple and noncontroversial enough that we can add it quickly, but if there are concerns from any type checker authors, I'd love to hear them.

9 23