[Feature Request] validate a given object against a type annotation as a function

[JakkuSakura]

Really love beartype. However, I couldn't find the method for validating a given object against a type annotation. I have to use some tricks. Is this available somewhere?

def check_pep_type_raise_exception(obj, annotation):
    import beartype.roar
    import beartype
    @beartype.beartype
    def check(o) -> annotation:
        return o

    try:
        check(obj)
        reason = None
    except beartype.roar.BeartypeCallHintPepReturnException as e:
        reason = e.args[0].split('return ')[-1]
    if reason:
        raise TypeException(reason)
    return True

[leycec]

Really love beartype.

Aww! Thanks, Qiu. Right back atcha. 🤗

However, I couldn't find the method for validating a given object against a type annotation.

Finally! Finally someone other than me wants this. Sadly, you are absolutely right. Because you're the first user to express interest in this, beartype currently lacks an explicit API for this. Your implementation is extremely clever, though; I'm insanely impressed with what you've cobbled together out of pure nothingness there. Wowza.

The only real-world issue with your hyper-intelligent approach is runtime efficiency. check_pep_type_raise_exception() dynamically declares one new throw-away closure check() every time it's called. That's absolutely unavoidable, but also absolutely slow. Still...

Your gargantuan intellect stupefies me. You're the first to think of something like that – and you're only a Uni student! 😮

Stumbling into a Bold Future

Let's talk official support. I hope to release beartype 0.10.0 in a few days. Official support for this feature will need to wait until our next beartype 0.11.0 release – which won't be until late January or February. That said, I promise you the official name for this function will be:

• beartype.is_bearable().

If you'd like to preserve forward compatibility with beartype ≥ 0.11.0, consider something like the following for now:

try:
    from beartype import is_bearable
except ImportError:
    def is_bearable(obj, annotation):
        import beartype.roar
        import beartype
        @beartype.beartype
        def check(o) -> annotation:
            return o
    
        try:
            check(obj)
            reason = None
        except beartype.roar.BeartypeCallHintPepReturnException as e:
            reason = e.args[0].split('return ')[-1]
        if reason:
            raise TypeException(reason)
        return True

When beartype 0.11.0 drops in a month or two, you can then reduce the above to just from beartype import is_bearable. How does that sound, Qiu?

Oh – and thanks so much for suggesting this! I'm delighted to meet a like-minded die-hard equally obsessed with hard-hittin' QA like this. Have a great start to 2022... and beyond.

[JakkuSakura]

Oh, the API sounds good enough for me. I'm implementing https://github.com/qiujiangkun/typedmodel with beartype as the only dependency, as a replacement of pydantic, but its type-validation is stupid and full of surprise, like treating type annotation standalone and in list differently, when standalone it raises an exception, but in a list, it converts something false negatively. Now with typedmodel, I have a similar experience as I'm working with Rust structs.

I'm in a research group about compiler optimization, code generation, and type inference.

[leycec]

pydantic, but its type-validation is stupid and full of surprise, like treating type annotation standalone and in list differently, when standalone it raises an exception, but in a list, it converts something false negatively.

...yikes. Suspicious behaviour like that makes my unibrow waggle suggestively. 🤨

beartype is substantially safer in this regard. Whereas pydantic tries really hard (and occasionally fails) to both validate and transform data, beartype only validates; we never transform anything into something else entirely. Safety first is our motto here.

I've occasionally contemplated adding pydantic-style support for transforms, conversions, and coercions. Then I stumble over issues like those you've submitted and realize I've subconsciously dodged multiple bullets. (Phew!)

Now with typedmodel, I have a similar experience as I'm working with Rust structs.

Yes. Your class Foo(typedmodel.BaseModel): example is endlessly intriguing – especially because the code underlying typedmodel.BaseModel is surprisingly concise and elegant. It's hard to beat 83 lines of code, right?

I mean... that's some extraordinarily efficient code there. I'm now considering adding a new feature strongly inspired by your BaseModel superclass – with attribution to you, of course! – directly to beartype itself. @dataclass.dataclass integration is something we'd all love to see – and BaseModel is an excellent first stab at that.

Kudos yet again there.

I'm in a research group about compiler optimization, code generation, and type inference.

Oh, wow! Congratulations. That sounds utterly fascinating. Drop us all a line when your next thesis and/or paper passes peer review – especially if you leverage beartype throughout your work. I'd love to read that.

[rsokl]

+1 for this feature! I will almost certainly have use for this in hydra-zen down the line.

[leycec]

You got it, our favourite Ryan! @beartype proudly supports all MIT beavers. This is something we've wanted for some time, too. That time is now coming.

The optimistic estimate is that support for this will land with beartype 0.11.0 in late February. Brace yourselves! The ride is gettin' bumpy. 🚁

[JakkuSakura]

The previous code has a bug, as in some cases invalid types still pass the test. Here's the fix

try:
    from beartype import is_bearable
except ImportError:
    def is_bearable(obj, annotation):
        import beartype.roar
        import beartype
        import typing
        old_type_checking = typing.TYPE_CHECKING
        typing.TYPE_CHECKING = False
        @beartype.beartype
        def check(o) -> annotation:
            return o

        typing.TYPE_CHECKING = old_type_checking
        try:
            check(obj)
            return True
        except beartype.roar.BeartypeCallHintPepReturnException as e:
            return False

[leycec]

OMG! Thanks a heap for that, Qiu. We're on the cusp of adding your awesome work to @beartype. So, this is incredibly helpful.

I wonder why typing.TYPE_CHECKING would need temporary monkey-patching, though. That's the conundrum, isn't it? The beartype codebase mostly ignores typing.TYPE_CHECKING. This must be for mypy compatibility, I assume? Do you happen to recall exactly which invalid types were reported as passing? There might be something meaningful we can do about this.

Thanks again, Qiu! You're a living typing legend.

[JakkuSakura]

In my project, I check a type against a list of annotations and get the corresponding element. Without this monkey-patching, it won't work sometimes. I'll see how to reproduce it.

I need a way to make sure type checking behave consistently, in case of not __debug__ or not.

if (
    # Optimized (e.g., option "-O" was passed to this interpreter) *OR*...
    not __debug__ or
    # Running under an external static type checker -- in which case there is
    # no benefit to attempting runtime type-checking whatsoever...
    #
    # Note that this test is largely pointless. By definition, static type
    # checkers should *NOT* actually run any code -- merely parse and analyze
    # that code. Ergo, this boolean constant should *ALWAYS* be false from the
    # runtime context under which @beartype is only ever run. Nonetheless, this
    # test is only performed once per process and is thus effectively free.
    TYPE_CHECKING
):

Edit: couldn't reproduce it anymore. Seems it was due to bugs somewhere else, maybe the__debug__ option was false.

[rsokl]

Edit: couldn't reproduce it anymore. Seems it was due to bugs somewhere else, maybe the__debug__ option was false.

whew. That makes a lot more sense to me now.

[leycec]

It is done. Weep with satisfaction as beartype now type-checks everything for you in constant-time on-demand. Check this now, beartype!

>>> from beartype.abby import is_bearable
>>> is_bearable(['Things', 'fall', 'apart;'], list[str])
True
>>> is_bearable(['the', 'centre', 'cannot', 'hold;'], list[int])
False

>>> from beartype.abby import die_if_unbearable
>>> die_if_unbearable(['And', 'what', 'rough', 'beast,'], list[str])
>>> die_if_unbearable(['its', 'hour', 'come', 'round'], list[int])
beartype.roar.BeartypeAbbyHintViolation: Object ['its', 'hour', 'come',
'round'] violates type hint list[int], as list index 0 item 'its' not
instance of int.

😮

Caveat emptor: the current implementation is painfully unoptimized, but will be optimized shortly. Since a slow API that exists >>>> a fast API that doesn't exist, we hope everyone will bear ^...heh with this temporary slowdown. This API should more than fast enough for general-purpose use, but cracks will show if you throw it at a tight inner loop.