Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Recommend reveal_type in PEP 484 #277

Closed
ilevkivskyi opened this issue Sep 3, 2016 · 10 comments
Closed

Recommend reveal_type in PEP 484 #277

ilevkivskyi opened this issue Sep 3, 2016 · 10 comments
Assignees
Labels
topic: feature Discussions about new features for Python's type annotations

Comments

@ilevkivskyi
Copy link
Member

ilevkivskyi commented Sep 3, 2016

When #136 will be fixed, it will be nice to have something that could be used in place of issubclass for "experimentation" with types. Mypy already provides such a function -- reveal_type. I think it works very well and maybe it is a good idea to add a recommendation to PEP 484 that static type checkers should provide a function to reveal the inferred types? Or maybe even add a function

def reveal_type(obj):
    print('Runtime type is:', getattr(obj, '__orig_class__',  type(obj)))
    return obj

to typing.py so that it can be used for this purpose by other type checkers.

@srittau
Copy link
Collaborator

srittau commented Nov 4, 2021

I wish reveal_type() was a Python builtin. Often when I test code, I have to temporarily comment out reveal_type calls, which is a bit annoying.

@srittau srittau added the topic: feature Discussions about new features for Python's type annotations label Nov 4, 2021
@sobolevn
Copy link
Member

sobolevn commented Nov 4, 2021

I use this hack:

from typing import TYPE_CHECKING

if not TYPE_CHECKING:
   globals()['reveal_type'] = print

@gvanrossum
Copy link
Member

gvanrossum commented Nov 4, 2021

I support making it a builtin. File a bpo issue and write a PR and I will add it.

@srittau
Copy link
Collaborator

srittau commented Nov 4, 2021

One idea I have in addition to @ilevkivskyi's code above is to use the warnings module instead of just printing the output. This allows filtering, adds special handling by test runners etc.

@erictraut
Copy link
Collaborator

erictraut commented Nov 5, 2021

If reveal_type is added as an actual builtin call, its full type signature will need to be formalized.

Would you be open to reveal_type returning a str (the actual revealed type) rather than returning the value passed as an input argument?

Pyright currently implements reveal_type such that the return type of the call is a literal string value of the revealed type.

This allows us to use it in test cases, like this:

def func(x: int, y: str):
   z = x if x > 3 else y
   t1: Literal['int | str'] = reveal_type(z)

We use this in thousands of places within pyright's test suites. It would be significant work to change this.

@gvanrossum
Copy link
Member

Hm. In mypy IIRC reveal_type(x) returns x. This makes it possible to wrap arbitrary subexpressions in it without changing their meaning. I would regret losing this.

@gvanrossum
Copy link
Member

You could introduce a new helper with the desired meaning in a pyright-specific header.

@erictraut
Copy link
Collaborator

This makes it possible to wrap arbitrary subexpressions in it without changing their meaning

Oh, that's clever. I hadn't considered that.

OK, we can introduce a new helper.

@JelleZijlstra JelleZijlstra self-assigned this Jan 22, 2022
@JelleZijlstra
Copy link
Member

I am implementing this by adding typing.reveal_type:

@JelleZijlstra
Copy link
Member

This will be in Python 3.11 and the next release of typing-extensions.

https://docs.python.org/3.11/library/typing.html#typing.reveal_type

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
topic: feature Discussions about new features for Python's type annotations
Projects
None yet
Development

No branches or pull requests

6 participants