El lun, 17 ene 2022 a las 8:37, Paul Bryan (<pbryan@anode.ca>) escribió:
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?
There's a couple of advantages: - Discoverability. I'd been thinking about this for a while, but my prompt for writing it up this morning was Petr Viktorin's query over on python-dev about a use of reveal_type() in PEP 673. Documenting reveal_type() in the typing module will make it easier for users to find out about it. Two type checkers (pyre and pyright) currently don't define reveal_type() in their documentation, but use it in examples anyway. - Standardization. Because reveal_type() has been spreading organically between type checkers, there are some differences in exact behavior. Standardizing that behavior will make code more portable across type checkers. - Type checker-independent use. If reveal_type() is in typing, we can use it in type checker-independent documentation, such as PEPs and https://typing.readthedocs.io/en/latest/. - Runtime use. Right now you'll get a NameError if you try to run code that uses reveal_type(). I don't think this will be a very common use case, but I could imagine wanting to run your test suite at the same time as you're using reveal_type() to debug typechecking.
Is the intent for the static type checker to monkey-patch the typing library to provide something different when it's running?
Static type checkers don't use the runtime definitions in typing.py, so there's no need to monkeypatch anything.
On Mon, 2022-01-17 at 07:14 -0800, Jelle Zijlstra wrote:
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-t... 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. _______________________________________________ Typing-sig mailing list -- typing-sig@python.org To unsubscribe send an email to typing-sig-leave@python.org https://mail.python.org/mailman3/lists/typing-sig.python.org/ Member address: pbryan@anode.ca