In the PR (https://github.com/python/cpython/pull/30839/), there was some concern that this function isn't broadly useful enough to add it. It's not as widely implemented as reveal_type() and doesn't get used as often with the type checkers that do implement it. In this thread there hasn't been much discussion so far about whether we should add reveal_locals() specifically. So I'd like to ask anyone with an opinion to speak up: Is reveal_locals() sufficiently useful that we should add it to the standard library? El sáb, 22 ene 2022 a las 14:32, Jelle Zijlstra (<jelle.zijlstra@gmail.com>) escribió:
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-type...) 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.