Mailman 3 January 2022 - Typing-sig

Proposal: typing.assert_never()
by Jelle Zijlstra 09 Feb '22

09 Feb '22

Another idea that came up in a few recent threads is a `typing.assert_never()` function, which indicates that some code is supposed to be unreachable. I will submit an implementation to CPython, and we can use this thread to work out any details (or to let me know that we shouldn't do this after all). # Specification We will add a new function `typing.assert_never()` with the following signature: def assert_never(arg: NoReturn, /) -> NoReturn: ... At runtime, this will unconditionally raise `RuntimeError(f"Unexpectedly reached {arg!r}")` (wording suggestions welcome). Type checkers should emit an error if the function is called with an argument that has a non-bottom type. Examples: match bool(): case True: pass case False: pass case _ as x: assert_never(x) # ok match int(): case 0: pass case 1: pass case _ as x: assert_never(x) # error: x is an int, not NoReturn # Motivation PEP 484 only allows NoReturn as a return type, but in practice all type checkers allow it in argument positions as a bottom type. Thus, a manually defined `assert_never()` function already has the behavior specified above. Adding the function to the standard library will make this behavior more discoverable for users. Relatedly, I opened https://bugs.python.org/issue46475 to document NoReturn being a general bottom type. # Open questions Suggestions welcome for better wording in the runtime error. There is a related proposal to rename NoReturn to Never. I'm lukewarm about that because renaming things always causes churn, but in any case let's discuss that separately.

6 8

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

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

04 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

type narrowing beyond single method
by Ilya Kamenshchikov 01 Feb '22

01 Feb '22

Hello, I have a problem with code like below: class Foo: def __init__(self) -> None: self.x: int | None = None def setup(self): self.x = 42 def add1(self): self.setup() assert self.x is not None, "expected setup to make self.x an integer." self.x += 1 # Operator "+=" not supported for types "int | None" and "int" def add2(self): self.setup() assert self.x is not None, "expected setup to make self.x an integer." self.x += 2 # Operator "+=" not supported for types "int | None" and "int" In the actual code there are even more than two methods that need asserts to avoid the type error involving initial value of None. A trivial DRY refactoring is to move this assert into the "setup" method. However, pyright type checker is not impressed by this refactoring, apparently its type narrowing only works for assert directly in the same code block. Does any other type checker support this? Would somebody else find such a feature useful, or is there a workaround I'm missing? If such implied type narrowing was to work, then an assert would be redundant altogether as assignment implies the same type guarantees as an assert. p.s. you might rightly suggest that the design of class `Foo` is at fault. It should just do complete initialization. The problem is that I'm trying to add types to an existing library and effort of changing this design + resulting user migrations are too much pain. I'm also hopeful that such type checking feat would be useful outside of bad design software. Best Regards, -- Ilya Kamen

3 3

Opened and changed typing issues week 2022-W04
by Typing Bot 31 Jan '22

31 Jan '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 opened last week: #1043 TypingError: type checker will emit error with a message specified in typing stubs opened by @Akuli https://github.com/python/typing/issues/1043 #1044 Idea: safe and unsafe strings opened by @Akuli https://github.com/python/typing/issues/1044 --------------------------------------------------- The following issues and pull requests were updated last week: #781 Literal of enum values opened by @vnmabus https://github.com/python/typing/issues/781 --------------------------------------------------- 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

SC Acceptance: PEP 673 -- Self Type
by Petr Viktorin 25 Jan '22

25 Jan '22

Hello Pradeep, James and Jelle, The Steering Council discussed PEP 673 -- Self Type, and unanimously decided to accept it. Congratulations! Please change the PEP status to Accepted, and merge the change to Python 3.11, at your convenience. Happy typing! - Petr (on behalf of the Python Steering Council)

2 1

Opened and changed typing issues week 2022-W03
by Typing Bot 24 Jan '22

24 Jan '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 opened last week: #1039 Annotate function which return a specific module (e.g. `-> Literal[np]`) opened by @Conchylicultor https://github.com/python/typing/issues/1039 --------------------------------------------------- The following issues and pull requests were updated last week: #277 Recommend reveal_type in PEP 484 opened by @ilevkivskyi https://github.com/python/typing/issues/277 --------------------------------------------------- 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

generics support for Enum
by Ethan Furman 24 Jan '22

24 Jan '22

Greetings! I'd like to add Generics support for Enum... at least I think I do. :-/ The magic seems to happen in `SomeMetaClass.__getitem__`, and it should be doable as `EnumType.__getitem__` currently only accepts strings, so types could easily take a different branch in the code, but I am entirely unsure of what that separate branch should do, what it should return, etc. Are there any pure-python classes in the stdlib (besides Generics) that I could use for inspiration? Or some documentation somewhere I could use? A basic tutorial so I can get a grip on all the terminology? Any and all help appreciated! -- ~Ethan~

4 3

Re: Proposal: typing.assert_type() and with typing.assert_error()
by Anton Agestam 24 Jan '22

24 Jan '22

I like both of these suggestions. I use both assertions on revealed types and on yielded errors on the types in phantom-types. The names are clear to me, and the fact they'd be namespaced under "typing" makes it blatantly clear that they are related to concepts of typing. I'd suggest defining assert_error() to accept arbitrary kwargs, so that context can be passed in specific for type checkers, e.g.: assert_error(mypy=["arg-type"], pyright=[...])

2 1