On Tue, Jan 18, 2022 at 12:25 PM Jelle Zijlstra <jelle.zijlstra@gmail.com> wrote:
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.
Yeah, probably not.
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)
I'd still be hesitant to add this to PEPs, even new PEPs, because once you know what reveal_type is, it rarely need an explanation (witness people here thinking that it was defined in PEP 484 -- in fact I searched that PEP myself :-). But the first bullet feels true, and just having the docs and the specification make it useful, so I am in favor of this. I think we should also add reveal_locals() and assert_type(), to promote, document and standardize them. -- --Guido van Rossum (python.org/~guido) *Pronouns: he/him **(why is my pronoun here?)* <http://feministing.com/2015/02/03/how-using-they-as-a-singular-pronoun-can-c...>