Hey :) Perhaps I've misunderstood you, but isn't the "typing" module exactly a shared namespace for external type checkers? As a consumer, it would be great to not have to worry about commenting out reveal_type or wrapping it in `if TYPE_CHECKING:`. On Mon, 17 Jan 2022, 18:51 Paul Bryan, <pbryan@anode.ca> wrote:
To me it seems weird, perhaps even wrong, to add these to stdlib, as they're expected to be implemented by external static type checking tools. If static type checkers want to share an API convention, wouldn't it be more appropriate to establish a shared namespace where they can implement these functions and keep them out of stdlib?
On Mon, 2022perhaps-01-17 at 19:12 +0100, Sebastian Rittau 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.
- Sebastian
_______________________________________________ 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
_______________________________________________ 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: capruce@gmail.com