El lun, 17 ene 2022 a las 19:10, Guido van Rossum (<guido@python.org>) escribió:

On Mon, Jan 17, 2022 at 10:12 AM Sebastian Rittau <srittau@rittau.biz> wrote:

Am 17.01.22 um 17:38 schrieb Paul Bryan:
> As a static type checking amateur, it's not clear to me what the aim
> of adding this to stdlib is. Is this to avoid the pitfalls of code
> containing calls to `reveal_type` when not running mypy or other
> static type checker? Is the intent for the static type checker to
> monkey-patch the typing library to provide something different when
> it's running?

This is an idea I wanted to bring up as well, but never came around to.
For me, it's mostly about convenience: Often when debugging, I add
reveal_type() statements and run the type checker and the tests
alternately. But currently this means I have to remember to comment out
the reveal_type() statement whenever I run the tests (and I usually
don't remember). This would help with this nuisance.

Indeed -- I have used this workflow (alternating between running a static checker and running the code) and sometimes I've even done things like

if not TYPE_CHECKING:

    reveal_type = print  # Good enough :-)

Still, I have a concern. Linters etc. tend to complain about unused imports. That means that you cannot leave the `from typing import reveal_type` in your code once you've removed the last reveal_type() call. But now when you want to use it, you'll have to add the import back in. So it would be much more convenient if it was an actual builtin.

I see your point, but I'm not sure we'll be able to meet the bar for adding a new builtin.

Also, I'm not proposing that type checkers remove the current behavior where reveal_type() is always an implicit builtin during type checking. So you'd only need to add the explicit import in two cases:

- When you want to also run your code at the same time (e.g. to run your test suite)

- When you want to communicate to readers where reveal_type() comes from (e.g. in a PEP example)