Thanks, Jelle. Out of curiousity, do most type checkers expect `reveal_type()` to be a builtin, or in the typing module? How would they cope with `reveal_type` defined and consumed from another module?

On Mon, 2022-01-31 at 07:26 -0800, Jelle Zijlstra wrote:

El lun, 31 ene 2022 a las 0:56, Paul Bryan (<pbryan@anode.ca>) escribió:

I do have a follow-up question:

If static type checkers are not executing the code in question (`reveal_type`), then wouldn't a well-placed (and formatted) comment do just as well? If so, what's the value of adding this to stdlib?

There's a few advantages:

- reveal_type() is already a well-established convention, all type checkers implement it

- A function is more discoverable for users than a magical comment

- We can give the function useful runtime behavior

- reveal_type() is an expression and can be put anywhere in the line. Consider the usage in https://github.com/microsoft/pyright/issues/2916#issuecomment-1025187284, for example—that would have been difficult to do with a magical comment.

 

On Sun, 2022-01-30 at 11:38 -0700, Carl Meyer wrote:

Hi Paul,

On Sun, Jan 30, 2022 at 11:22 AM Paul Bryan <pbryan@anode.ca> wrote:

I suspect that `reveal_type` will see very little (if any) use at runtime, and will likely be removed by developers when static type debugging is completed to avoid console noise. If this is not true (if `reveal_type` may be retained in code after debugging) then I think it would actually be better for it to have no runtime behavior (e.g. like `cast`).

I see it as a debug tool that should be removed before commit, so for that use case the “print type” behavior is useful for iterating and going between running the code and type checking it, with useful debug type information both ways; it’s especially interesting to know if the runtime type does not match the static type. 

There’s been some discussion also of it’s possible use in test suites for typed libraries, but I haven’t fully followed the ins and outs of that. 

Carl