On Sun, Jan 30, 2022 at 10:39 AM Carl Meyer <carl@oddbird.net> 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.
I was skeptical originally, for a reason similar to Paul's objection (IIUC). But I've come across the use case (flipping back and forth between static type checking and running the code to debug it) that I like the proposed solution. IMO accidentally leaving a reveal_type() call in when committing the code is a minor sin, comparable to leaving in a debug print() call. It happens, someone notices, you fix it. -- --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-change-the-world/>