Printing deep type

[Moosems]

I want to have beartype print out the proper type annotation for a variable because I can't seem to do it right myself. Example:

from beartype.typing import Callable
from pygments.lexers import PythonLexer
from pygments.lexer import RegexLexer
from pygments.token import _TokenType
lexer: RegexLexer = PythonLexer()
root_tokens: list[str] | list[tuple[str, _TokenType | Callable, str]] = (
    lexer.tokens["root"]
)
print(root_tokens)

Now try using beartype_this_package with that. I could just use type list and call it a day but that just feels wrong. The thing is this list can be different depending on what Lexer I use and theres so many possible subtle variations possible and I don't have the time to write that all out when the logic I use to deal with that list works anyway.

[leycec]

Type inference. Yes. So much yes! Full-blown type inference support in @beartype would be delightful. Someone make a @beartype-based runtime equivalent of the mypy-specific reveal_type() fake function happen. I revel in this idea.

reveal_type() tends to be rather useless in practice. mypy is just a static type-checker. mypy doesn't actually run at runtime and thus generally no idea what it's talking about. The set of all type hints that static type-checkers like mypy and pyright can correctly infer is a lot smaller than the set of all type hints that runtime type-checkers like @beartype and typeguard can correctly infer – in theory, anyway.

I dimly recall @wesselb the Wise needing something similar for Plum, maybe? Does Plum do any sort of runtime type inference? Probably not, huh? Yeah. That was always gonna be a longshot. But if Plum does do some sort of runtime type inference, perhaps we could upstream that into @beartype itself as a new public API... which @leycec then has to laboriously maintain for the rest of his life. Gah! What am I doing!? This sounds suspiciously like maintenance prison.

Ahem... What I meant is that this is a fascinating and incredibly relevant discussion. Thanks so much for igniting this lit bonfire, @Moosems. 🔥

[Moosems]

Technically no one can force you to maintain it, we can only request it strongly 😄

[leycec]

Oh, I'd love to! Don't get me wrong. I love maintenance prison. This is a wonderful idea. Therefore, it must happen.

Let's wait for @wesselb to save the day with a 0-day solution. Please, @wesselb! Save me from trying to do this from scratch and then failing pathetically! 🙏

[wesselb]

@leycec, in the past Plum included a function type_of, but Plum has since been refactored to operate without needing a function type_of. type_of (or any kind of runtime reveal_type-style function) turned out to be an absolute nightmare to comprehensively implement, so I was very glad to get rid if it. I applaud you for attempting trying to implement such a monstrosity The Right Way (tm). 😱

This gets me very curious! @leycec, how do you define what the output of infer_hint should be? Namely, for a given object x, there are multiple types t such that x is an instance of t. Should reveal type give back any such t, where it doesn’t matter which one?

A reasonable take would be to say that it should give the narrowest / most specific such type t. This, however, would not be very useful, because then the type of x would always be Literal[x].

This makes wonder how infer_hint should be formally defined. I can see circumstances where infer_hint(1) = int is desired, but also circumstances where one would want infer_hint(1) = Literal[1]. Hmm. Any thoughts?

[leycec]

Fantastic comment, @wesselb! You have inspired me to author a tedious essay on type hint inference ambiguities which we will surely both regret in the morning.

[leycec]

Tell @Moosems what he's won, GitHub Bear! It's... our newest feature request. Also, I implemented this tonight. 🤣