[Feature Request] Granular exception messages for synthesized beartype validators

[dycw]

Hi, I have been studying this library and noticed that the README suggests one prefer conjoining ("and"-ing) conditions over enumerating them (","-separating) them.

from dataclasses import dataclass
from typing import Annotated
from beartype import beartype

@dataclass
class Foo:
    x: int
    y: int

@beartype
def conjoined(
    x, y
) -> Annotated[
    "Foo",
    Is[lambda foo: foo.x + foo.y >= 0] # force separation of lines so only 1 lambda per line
    & Is[lambda foo: foo.x + foo.y <= 10],
]:
    return Foo(x, y)

conjoined(100, 100)

BeartypeCallHintPepReturnException: @beartyped conjoined() return "Foo(x=100, y=100)" violates type hint typing.Annotated[ForwardRef('Foo'), Is[lambda foo: foo.x + foo.y >= 0] & Is[lambda foo: foo.x + foo.y <= 10]], as "Foo(x=100, y=100)" violates validator Is[lambda foo: foo.x + foo.y >= 0] & Is[lambda foo: foo.x + foo.y <= 10].

However, this doesn't go in and tell me which condition failed (maybe 1, maybe all).

Enumeration seems to do the trick though:

@beartype
def enumerated(
    x, y
) -> Annotated[
    "Foo",
    Is[lambda foo: foo.x + foo.y >= 0],
    Is[lambda foo: foo.x + foo.y <= 10],
]:
    return Foo(x, y)

enumerated(100, 100)

BeartypeCallHintPepReturnException: @beartyped enumerated() return "Foo(x=100, y=100)" violates type hint typing.Annotated[ForwardRef('Foo'), Is[lambda foo: foo.x + foo.y >= 0], Is[lambda foo: foo.x + foo.y <= 10]], as "Foo(x=100, y=100)" violates validator Is[lambda foo: foo.x + foo.y <= 10].

To be it seems enumerated conditions could / should be preferred. Could you explain any arguments in favour of conjunction?

[leycec]

Could you explain any arguments in favour of conjunction?

None whatsoever. Just kidding. Almost had you there for a sec, huh? Okay. So:

• The advantages are legion! Conjunction is deeply composable with both disjunction and negation, enabling synthesis of non-trivial conditions that often can't be expressed any other way.
• The disadvantages are few! Namely, exactly what you just noticed. 😉

But... you're absolutely right. beartype should always raise human-readable exceptions. And that's doubly the case for complex high-level validators composed from lower-level validators. beartype currently isn't raising human-readable exceptions for those. That's bad. We'd better fix that before anyone else notices, so I've prioritized this above everything else I'm currently doing here.

Thanks for the detailed heads up on this badness, Derek. You're awesome – and so are all these helpful issues you've been opening up! Two misshapen thumbs way up. 👍 👍

[leycec]

To remind myself exactly what I'm doing here, I've taken the liberty of "lightly" editing the issue title.

It's for the good of my future self. Really, that guy wouldn't remember his cat's name if it wasn't soldered straight onto his breadboard. 🧓

[dycw]

Thanks, merci and ありがとうございます for the bearific, pawesome library!

P.S. Really looking forward to O(n log n) runtime checking.

[leycec]

Awwwww. You are too nice, Derek. I graciously accept your multilingual merci + ありがとうございます k-k-k-iller combo and humbly boomerang you back a de rien + どういたしまして extended finisher.

Fist-bumping high fives all around! ✋

O(n log n) runtime checking.

...heh. My facial twitch just got worse. Please tell me you meant O(log n). Please. If so, then... yes! We'd love to do both that and O(n) runtime type-checking for you and everyone. All I ask in return is five spare body clones willing to do my absolute bidding without trying to replace me.

Body clones: can't really trust 'em, can't really open-source without 'em.

[dycw]

Lol good catch. Without my normal office Mon-Fri coffee, I'm not quite as sharp. I can do O(n log n) by myself lol.

[leycec]

It begins. Thanks again for all the apropos issues, Derek. You rock everything. 🪨 ^{← unsure what that is}

[leycec]

Boom. Catastrophic explosions can be heard ominously rumbling in the distance as dust from the ceiling showers around your fragile laptop monitor. This can only mean one thing...

Either Godzilla and Mothra about to tumble on your front porch or this issue was brutally resolved! Yup. It's actually the latter. beartype 0.10.0 (to be released before 2022, maybe: that's a promise) now appends an exhaustive diagnosis explaining "Wtf, bro?" to type hinting failures resulting from beartype validators: e.g.,

>>> from dataclasses import dataclass
>>> from typing import Annotated
>>> from beartype import beartype
>>> from beartype.vale import Is
>>> @dataclass
... class Foo:
...     x: int
...     y: int
>>> @beartype
... def conjoined(
...     x, y
... ) -> Annotated[
...     "Foo",
...     Is[lambda foo: foo.x + foo.y >= 0] # force separation of lines so only 1 lambda per line
...     & Is[lambda foo: foo.x + foo.y <= 10],
... ]:
...     return Foo(x, y)
>>> conjoined(100, 100)
Traceback (most recent call last):
  File "/home/leycec/tmp/sappy.py", line 22, in <module>
    conjoined(100, 100)
  File "<string>", line 20, in conjoined
  File "/home/leycec/py/beartype/beartype/_decor/_error/errormain.py", line 301, in raise_pep_call_exception
    raise exception_cls(  # type: ignore[misc]
beartype.roar.BeartypeCallHintPepReturnException: @beartyped conjoined() return "Foo(x=100, y=100)" violates type hint typing.Annotated[ForwardRef('Foo'), Is[lambda foo: foo.x + foo.y >= 0] & Is[lambda foo: foo.x + foo.y <= 10]], as "Foo(x=100, y=100)" violates validator Is[lambda foo: foo.x + foo.y >= 0] & Is[lambda foo: foo.x + foo.y <= 10]:
    False == (
     True ==     Is[lambda foo: foo.x + foo.y >= 0] &
    False ==     Is[lambda foo: foo.x + foo.y <= 10]
             ).

Of course, validator diagnoses elegantly scale to deeply nested validators with properly indented pretty-printing. We may all be thankful for that, because deeply nested validators get crazy like Godzilla hopped up on too much spent plutonium rods dumped off the Bay of Tokyo yet again:

>>> from beartype import beartype
>>> from beartype.vale import Is
>>> from typing import Annotated
>>> IsLengthy = Is[lambda text: len(text) > 80]
>>> IsSentence = Is[lambda text: text and text[-1] == '.']
>>> IsQuoted = Is[lambda text: '"' in text or "'" in text]
>>> IsLengthyOrUnquotedSentence = IsLengthy | (IsSentence & ~IsQuoted)
>>> @beartype
... def still_life(serenity_painted_death: Annotated[
...     str, IsLengthyOrUnquotedSentence]) -> str:
...     return serenity_painted_death * 666  # <-- feels good
>>> still_life('Black paragon in lingering breath. "Yeah!" White-faced...')
Traceback (most recent call last):
  File "/home/leycec/tmp/sappy.py", line 16, in <module>
    still_life('Black paragon in lingering breath. "Yeah!" White-faced...')
  File "<string>", line 24, in still_life
  File "/home/leycec/py/beartype/beartype/_decor/_error/errormain.py", line 301, in raise_pep_call_exception
    raise exception_cls(  # type: ignore[misc]
beartype.roar.BeartypeCallHintPepParamException: @beartyped still_life() parameter serenity_painted_death='Black paragon in lingering breath. "Yeah!" White-faced...' violates type hint typing.Annotated[str, Is[lambda text: len(text) > 80] | Is[lambda text: text and text[-1] == '.'] & ~Is[lambda text: '"' in text or "'" in text]], as 'Black paragon in lingering breath. "Yeah!" White-faced...' violates validator Is[lambda text: len(text) > 80] | Is[lambda text: text and text[-1] == '.'] & ~Is[lambda text: '"' in text or "'" in text]:
    False == (
    False ==     Is[lambda text: len(text) > 80] |
    False ==     (
     True ==         Is[lambda text: text and text[-1] == '.'] &
    False ==         ~(
     True ==             Is[lambda text: '"' in text or "'" in text]
                     )
                 )
             ).

The sweat on my brow is real. 😅 💦

[dycw]

Quick, someone get @leycec some water — he's on fire!

This is an awesome feature, think beartype 0.10 might be an awesome Christmas present!