[Documentation] Document @dataclass integration better

[JulesGM]

Big fan of the project.
I was thinking that something like

@beartype
@dataclasses.dataclass
class Whatever:
    something: int
    other_thing: string


if __name__ == "__main__":
    asd = Whatever(123.321, b"Other error")  # Beartype error

Would be really great.

[leycec]

YES. Let us quietly reach for the open throat of pydantic under the veiled cover of moonlit darkness, for such is the dominion of... Actually, let's just do this without all the creepy metaphors. (That's why listening to five continuous hours of Norwegian black metal has real-life consequences, people.)

Srsly, tho. This must happen. You even stacked the decorators correctly, layering @beartype onto the standard @dataclasses.dataclass decorator without replacing the latter with our own ad-hoc @beartype.dataclass decorator. This is the Way. You now gratefully receive five golden sunbursts in acknowledgement of your contributions to mankind, Jules. 🔆 ⭐ 🌟 ☀️ 🌞

@leycec Has a Dream

I've always believed that:

• Pydantic's substitution of the standard @dataclasses.dataclass decorator with its own ad-hoc @pydantic.dataclasses.dataclass decorator is the fundamentally wrong approach. Let the Python standard library do what the Python standard library excels at, which is everything except type-checking, data science, and web dev. Don't reinvent the wheel. The wheel already exists, is well-tested, is well-maintained by a large international consortium of developers who are both better paid and more talented than me, ^{i see a correlation between those two things} and has been proven to behave as expected. Just use that existing wheel, yo!
• Pydantic's heavyweight BaseModel approach is also the fundamentally wrong approach – because it's heavyweight. As soon as you require user-defined classes to subclass your custom third-party abstract base class (ABC) whose own class is a custom third-party metaclass that conflicts with the only standard metaclass that matters (I speak, of course, of abc.ABCMeta, whose very classname is holy and divine), you invite horrifying metaclass and subclass (e.g., "Diamond Problem") conflicts. This is why pydantic questions on StackOverflow reduce to: "Pydantic class conflict. Help me, O' Nordic Gods!?!?"

Let's not do either of those things. The key to avoiding those things is to dynamically inspect and generate code at decoration time. If you do that, you don't need dark metaclass or superclass magic at variable access time – because you've already front-loaded all the dark magic to decoration time, where dark magic properly belongs.

Of course, dynamically inspecting and generating code at decoration time is already the core of what @beartype does. So that's noice. We just need to generalize what @beartype does to now cover classes as well.

Admittedly, that's kinda non-trivial. ←_{understatement alert} But non-trivial means fun, right? Right? I also love co-opting competitor ideas and folding them like a rapacious cult of Genestealers into our own genomic codebase.

^{pretty sure we're the purple guys in this metaphor}

Decorate Them All... And in the Darkness Type-check Them

You may have guessed, but this exact issue was my principal rationale for beartype validators. Everything's been leading up to this, really.

Now that beartype validators support Python ≥ 3.6 (via the typing_extensions.Annotated backport under Python < 3.9 and the official
typing.Annotated factory under Python ≥ 3.9), the stage is locked, loaded, and primed for beartype dataclasses.

In theory, generalizing @beartype to decorate classes shouldn't be too excrutiating. Here's how @leycec optimistically sees it. Our main task is to inspect the dictionary of the class currently being decorated and, for each class or instance variable declared at class scope, replace that variable with a dynamically generated data descriptor type-checking that variable in O(1) time after each assignment to that variable.

In theory, that sounds trivial. Okay... so it really doesn't. But let's pretend, because it's late and my tenuous grip on reality only has so much wiggle room.

In practice, the devil-in-the-details will be minimizing space costs. We really don't want to dynamically generate one new data descriptor for each class or instance variable. We want to cache data descriptors for subsequent reuse, because it's likely multiple classes will share class or instance variables annotated by the same type hints: e.g.,

@beartype
@dataclasses.dataclass
class LikeWhatever:
    something: int
    other_thing: List[str]

@beartype
@dataclasses.dataclass
class LikeIKnowRight:
    one_more_thing: List[str]   # <-- reuse LikeWhatever.one_thing's data descriptor
    yet_another_thing: str      # <-- reuse LikeWhatever.something's data descriptor

Phew. I feel even older just thinking about this. Since our first priority for the remainder of 2021 and probably most of 2022 ^{...let's be honest} is deep type-checking for all remaining PEP 484- and 585-compliant type hints, fulfilling this feature request that everyone really wants will have to moulder on the back burner for just a little bit.

Let's choose to believe that one day even type-checking bears can fly.

[antonagestam]

I'm currently experimenting with this decorator, which seems to work fine because __init__ gets __annotations__ correctly set by the dataclass decorator.

from dataclasses import is_dataclass
from typing import TypeVar

import beartype

T = TypeVar("T")


def beartyped(cls: type[T]) -> type[T]:
    assert is_dataclass(cls)
    cls.__init__ = beartype.beartype(cls.__init__)  # type: ignore[assignment]
    return cls

[JulesGM]

what @antonagestam suggests is what I personally was looking for, just doing arg type-checking on the __init__ call of dataclasses.

[JulesGM]

I understand that making class decorators behave this way (meaning, be a shorthand for decorating whatever init the class ends up with) would hamper the development of further class decorators though.

For a regular class, one would just add the beartype decorator to the init call. In the case of dataclasses however... it's automatically generated. Maybe a @beartype.check_init or @beartype.decorate_init decorator that one uses on class declaration could work.

@beartype.decorate_init
@dataclasses.dataclass
class Whatever:
    something: int
    other_thing: string


if __name__ == "__main__":
    asd = Whatever(123.321, b"Other error")  # Beartype error

[leycec]

Ah... I finally get it. </wet_forehead_smacking_sound>

We're not talking about type-checking class or instance variables at assignment time, which is a hard but "fun" problem; we're talking about type-checking in-memory callables dynamically generated by an earlier decorator like @dataclasses.dataclass, which is an easier and maybe even funner problem.

Indeed, this bears ^{...see wut i did there} some rumination. It'd be nice if whatever API we gin up in our bathtub cleanly generalizes to all dynamically generated callables – not just __init__() constructors synthesized by @dataclasses.dataclass.

I mean, __init__() constructors synthesized by @dataclasses.dataclass are the obvious use case. Sure. Can't argue there. But something similarly devilish is bound to crop up like a mouldy piece of organic broccoli on our dinner plate at some point.

Everything Should Work with Me Doing Nothing

Fortunately for my RSI-riddled fingers, this should already automagically happen once we generalize @beartype to handle classes. Why? Because @beartype will automagically apply itself to all methods of each decorated class – including in-memory methods dynamically generated by an earlier decorator like @dataclasses.dataclass.

In theory, @beartype shouldn't even be able to distinguish between on-disk methods that you explicitly write and in-memory methods that are implicitly written for you by someone else. As far as @beartype is concerned, they're all just unbound methods in the same class dictionary dir(cls). @beartype will type-check them all! ^muhaha

But What Should We Do until You Actually Do Something?

...what @antonagestam suggests. You knew that was coming, didn't you?

I'd probably rename @beartyped to something a bit more unambiguous like @beartype_decorate_init (as you smartly suggest, @JulesGM) or just @beartype_init or something.

Since @beartype will automagically handle all of this for everyone without requiring API changes when we generalize @beartype to decorate classes, I'd rather hold off on hard-coding something like @beartype.decorate_init into the codebase. We'd end up deprecating that anyway, at which point everyone would shake their mottled fists at us and demand all their GitHub stars back.

Does all of that sound reasonable? If not, I have five hours of Swedish melodic death metal that desperately needs listening to... cues Hypocrisy Destroys Wacken 🎧

[JakkuSakura]

Recently I developed typedmodel for this. Under the hook it's MetaClass and beartype. It's not very runtime efficient, but strict. Speed is not anymore the main concern when I choose python

https://github.com/qiujiangkun/typedmodel

[leycec]

Speed is not anymore the main concern when I choose python

...truer words were never spoken.

Relatedly, it's abundantly clear that everyone just wants @antonagestam's wonderful @beartyped decorator. It's wonderful because it works now and is literally two joyous lines of code, which is more than I can say for anything I've done about this – which is nothing.

Here's the short-term winning game plan:

• Shamelessly copy-paste @antonagestam's aforementioned monument to clever one-liners into the @beartype decorator.
• Release beartype 0.10.0 in a few days with that.
• Wait several years to several decades.
• Add real support for decorating classes to @beartype.
• Release beartype 0.99.0 with that.

Specifically, I'm contemplating this:

from dataclasses import dataclass, is_dataclass
from typing import Type

T = TypeVar("T")

def beartype(thing: T) -> T:
    # Recursion, because exhausting the stack is "fun."
    if isinstance(thing, type):
        if is_dataclass(thing):
            thing.__init__ = beartype(thing.__init__)  # type: ignore[assignment]
            return thing

        raise BeartypeWrappeeException(
            f'{repr(thing)} not a @dataclasses.dataclass, yo. What up?')

    # Else, do everything else we currently do.
    ...

Sound good? Great. Let's do this thing. Perpetual thanks to @antonagestam for the no-nonsense contribution and to everyone else for continually referencing the obvious move I should have made several months ago.

Speak now or forever hold my beer.

[leycec]

[leycec]

As it was written, so it was done. Thanks to all for continually kicking this into nitrous-injected high-gear and to @antonagestam particularly for the game-changing one-liner. 2022 is looking up already; the evidence is here.

Nitrous injection: engage!

[JulesGM]

That's great, thanks !

…

On Sat., Jan. 8, 2022, 2:57 a.m. Cecil Curry, ***@***.***> wrote: Closed #56 <#56>. — Reply to this email directly, view it on GitHub <#56 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAYU34MXBC2P76FJRTNL54DUU7U6FANCNFSM5FSWQ6OQ> . Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>. You are receiving this because you were mentioned.Message ID: ***@***.***>

[JulesGM]

Would changing `__setattr__` also be this simple? On Sat., Jan. 8, 2022, 4:40 a.m. Jules Gagnon-Marchand, < ***@***.***> wrote:

…

That's great, thanks ! On Sat., Jan. 8, 2022, 2:57 a.m. Cecil Curry, ***@***.***> wrote: > Closed #56 <#56>. > > — > Reply to this email directly, view it on GitHub > <#56 (comment)>, or > unsubscribe > <https://github.com/notifications/unsubscribe-auth/AAYU34MXBC2P76FJRTNL54DUU7U6FANCNFSM5FSWQ6OQ> > . > Triage notifications on the go with GitHub Mobile for iOS > <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> > or Android > <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>. > > You are receiving this because you were mentioned.Message ID: > ***@***.***> >

[leycec]

Ah! Spot-on point, as always.

In theory, type-checking __setattr__() for @dataclass-decorated classes enabling frozen=True should be trivial as well – assuming @dataclass synthesizes a __setattr__() dunder method that's just as nicely annotated as __init__(). Is that the case? I... have no idea whatsoever.

Allow me to scratch my chin thoughtfully while top men look into this.

[posita]

Allow me to scratch my chin thoughtfully while top men look into this.

Apologies in advance. I'm ethically (and—in some jurisdictions—legally) obligated to post this:

[leycec]

ohsh—

Literally cannot believe that obliquely referencing "top men" was enough to trigger @posita's 80's neural net. You've finely honed that neocortex on the finest chad-tier media yet produced by humankind; now, you are literally inside my mind and I'm not sure how to feel about that. Kuato would like to have a word.

[leycec]

@JulesGM: Sadly, @dataclass fails to annotate the __setattr__() or __delattr__() methods it synthesizes. Of course, that kinda makes sense; these methods just unconditionally raise dataclasses.FrozenInstanceError exceptions when they're called. Annotating something guaranteed to fail would be sorta pointless, right?

But please do shoot us another feature request if you think up anything else ingenious. An obvious example would be for @beartype to auto-generate type-checking data descriptors for all dataclass fields, which would type-check attempts to reassign those fields. I want this.

Let's make every dream come true in 2022.

[JulesGM]

Well, dataclasses aren't always frozen? Is the method decorated if the dataclass is not frozen? Can we just decorate in that case?

…

On Sat., Jan. 8, 2022, 10:54 p.m. Cecil Curry, ***@***.***> wrote: @JulesGM <https://github.com/JulesGM>: Sadly, @DataClass fails to annotate the __setattr__() or __delattr__() methods it synthesizes. Of course, that kinda makes sense; these methods just unconditionally raise dataclasses.FrozenInstanceError exceptions when they're called. Annotating something guaranteed to fail would be sorta pointless, right? But please *do* shoot us another feature request if you think up anything else ingenious. An obvious example would be for @beartype to auto-generate type-checking data descriptors <https://realpython.com/python-descriptors> for all dataclass fields, which would type-check attempts to reassign those fields. I want this. Let's make every dream come true in 2022. — Reply to this email directly, view it on GitHub <#56 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAYU34PQIVDZCEX7DC6VRWLUVEBHFANCNFSM5FSWQ6OQ> . Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>. You are receiving this because you were mentioned.Message ID: ***@***.***>

[leycec]

Well, dataclasses aren't always frozen?

wut u say!?!?

Of course, you are correct. It was my (mis)understanding from the official documentation that @dataclass only synthesizes __setattr__() and __delattr__() methods when passed frozen=True – but perhaps this too is a baldfaced spittle-flecked lie and @dataclass is actually unconditionally injecting __setattr__() and __delattr__() into everything?

Is the method decorated if the dataclass is not frozen?

Nope, according to my limited grasp of physical reality anyway. The official documentation reads:

frozen: If true (the default is False), assigning to fields will generate an exception. This emulates read-only frozen instances. If __setattr__() or __delattr__() is defined in the class, then TypeError is raised.

I take this to mean that @dataclass intentionally avoids defining __setattr__() and __delattr__() methods for you unless it absolutely has to (e.g., when frozen=True). Why? Because doing so would conflict with user-defined __setattr__() and __delattr__() methods, which would be bad.

Can we just decorate in that case?

If by "decorate," you mean "manually define @beartype-decorated __setattr__() and __delattr__() methods," the answer is: "Yes, please. This is the way. Do it for Johnny."

Minimal-length example from our Cheatsheet or it didn't happen, so:

# Import the requisite machinery. Note this requires Python ≥ 3.8.
from dataclasses import dataclass, InitVar

# User-defined dataclass. @beartype currently only type-checks the implicit
# __init__() method generated by @dataclass. Fields are type-checked *ONLY*
# at initialization time and thus *NOT* type-checked when reassigned to.
@beartype
@dataclass
class MyDataclass:
    # Annotate fields with PEP-compliant type hints.
    field_must_satisfy_builtin_type: InitVar[str]
    field_must_satisfy_pep604_union: str | None = None

    # Decorate explicit methods with @beartype as above.
    @beartype
    def __post_init__(self, field_must_satisfy_builtin_type: str) -> None:
        if self.field_must_satisfy_pep604_union is None:
            self.field_must_satisfy_pep604_union = (
                field_must_satisfy_builtin_type)

@dataclass API: why you so confusing? 😬

[JulesGM]

So, how about @beartype defining a default __setattr__ if there aren't any user-defined ones?
I guess there is a line that must be put, where support for most use cases of dataclasses ends and support for regular classes begins. I do feel that maybe only defining type-checking __setattr__ if there aren't user-defined ones keeps us on the good side of the line.
BTW, thanks for all your awesome work and super pleasant energy, as always, Cecil.

[leycec]

So, how about @beartype defining a default __setattr__ if there aren't any user-defined ones?

Heh. You're brilliant, so you went there. Because I'm less brilliant, please bear ^heh with me.

I'm pretty sure (but not certain) you're wondering when @beartype will type-check attempts to reassign fields after dataclass instantiation, right? In other words, you want this:

>>> @beartype
>>> @dataclass
>>> class DoItDoIt(object):
....     check_it_check_it: int = 0xDEADBABE
>>> do_it_do_it = DoItDoIt()
>>> do_it_do_it.check_it_check_it = 'This is an int. I swear.'
beartype.roar.BeartypeException: "This is an int. I swear."
is not actually an int. Your swears mean nothing!

If so, you're in deep luck. There are innumerably many ways to accomplish that lofty goal – and @beartype synthesizing a type-checking __setattr__() for you is (surprisingly!) one of the worst, mostly because of the aforementioned conflict with user-defined __setattr__() methods.

The best approach (from my limited understanding of physical reality) is to improve:

...@beartype to auto-generate type-checking data descriptors for all dataclass fields, which would type-check attempts to reassign those fields. I want this.

Data descriptors are dark and profane Python magic, but the core takeaway here is that:

• For each field of your dataclass:
  • @beartype will entirely replace that field with a new data descriptor of the same name masquerading as that field, whose:
    • __get__() method just unconditionally returns that field.
    • __set__() method (in order):
      1. Type-checks the passed value.
      2. If that type-check succeeds, sets that field to that value.

That's more-or-less how CPython implements the standard @property decorator, for example. I'm genuinely surprised that @dataclass(frozen=True) is implemented with __setattr__() rather than data descriptors, as the latter are always preferable to the former.

Someone who in not me dropped the greasy ball there. 😬

[antonagestam]

@leycec Wouldn't you need to define __setattr__ anyway to raise when assigning to undefined fields? I'm guessing now, but it seems like having only __setattr__ would result in fewer function calls as opposed to __setattr__ + property.

Anyways, as a "datapoint", I think it's completely reasonable to not support checking types om assignment. But then again, I also think having frozen=False as default was a mistake ;)

[leycec]

Wouldn't you need to define __setattr__ anyway to raise when assigning to undefined fields?

You ask me this troubling question, Anton. To better understand my delicate position, let me rephrase your question as:

Should @beartype prevent third parties from monkey-patching your @dataclass?

First, let's quietly admit to ourselves from the filthy confines of our ice-encrusted northerly mancaves that @beartype itself is a third-party monkey-patching your @dataclass to implement its diabolical data descriptor scheme. Hypocrisy, thy name is @beartype.

Second, let's quietly point to the sign on the wall reading @dataclass(slots=True). CPython 3.10 (and sorta prior CPython releases) already ships with built-in support for prohibiting unwanted field assignments, because CPython 3.10 is the Big Boss:

from dataclasses import dataclass

# Do you believe in miracles?
@dataclass(frozen=True, slots=True)
class Point:
    x: int = 0
    y: int = 0

So, the answer to this question and more is: "By the dessicated beard of Odin, this must not be." Thus spake the Bear.

...I think it's completely reasonable to not support checking types on assignment.

...yup. I'm right there with you – by default, anyway.

My main concern with check-on-assignment is the performance hit, because when isn't the performance hit my main concern? Never, that's when it isn't. ^←wut

In this case, each assignment costs you the function overhead of calling a data descriptor's __set__() method. In some contexts, that's fine; in others, the machine learning guys are already parading my head on a pike in downtown Gothenburg if I enable that by default in @beartype.

To appease everyone, I'm currently finalizing a configuration API for (wait-for-it) beartype 0.10.0 to be released in a few more days I swear this by the frayed beard of Odin. I'm contemplating a hypothetical configuration option is_check_var_assignment=True for the next-next beartype 0.11.0 release cycle enabling users to type-check field reassignment on a @dataclass-by-@dataclass basis: e.g.,

from beartype import beartype, BeartypeConf
from dataclasses import dataclass

# Don't ask why this looks so awkward. Don't.
@beartype(conf=BeartypeConf(is_check_var_assignment=True))
@dataclass
class Point:
    x: int = 0
    y: int = 0

But then again, I also think having frozen=False as default was a mistake ;)

...heh. A fellow frozen-favouring gentleman of culture, I see. I'm right there with you yet again, actually. What is this, Group Hug Time!?!? It may very well be.

The Big Takeaway from functional programming is that a shockingly ^😨 large class of bugs can be entirely eliminated by minimizing (or even prohibiting) object mutation. Of course, doing so usually also comes at a minor cost of pillaging and burning reducing the usability of your API – but I'm willing to sacrifice your API at the golden altar of robustness if you are.

I'm possibly still jelly that Rubyists got Object#freeze() and Object#frozen methods out-of-the-box, while Pythonistas can't even get robust freezing and slotting semantics in 2022 over here. Matz, we summon thee to finally join the Python world.

[antonagestam]

Sorry, I was bit vague, this remark:

Wouldn't you need to define __setattr__ anyway to raise when assigning to undefined fields?

Was in response to:

I'm genuinely surprised that @dataclass(frozen=True) is implemented with __setattr__()

E.g. just reasoning as to why frozeness is implemented with __setattr__().

And, it turns out I was misinformed, I for some reason thought the below would yield an error. Since it doesn't you're most likely right about it being weird that frozen=True isn't implemented with descriptors.

>>> from dataclasses import dataclass
>>> @dataclass(frozen=True)
... class A: ...
... 
>>> A.foo = "bar"

Completely agree about frozeness generally, my mind keeps grasping for a Python with much less mutability!

[leycec]

...my mind keeps grasping for a Python with much less mutability!

...heh. So, I have bad news and I have good news.

The bad news is Guido and Alex Martelli intentionally scuttled a working PEP proposal to introduce a freeze protocol via a new freeze() builtin that was on the Standards Track two-and-a-half decades ago. The good news is Guido and Alex Martelli were wrong.

Martelli's caustic rebuttal of PEP 351 makes utterly no sense from the rear view window of 2022. A throbbing varicose vein (blotched with ugly purple mottling, of course!) pops out on my forehead whenever I revisit that rebuttal. Everyone on Python's Steering Committee at the time badly missed the boat, which is just:

You freeze objects to eliminate bugs. That is all.

Instead, Martelli kicks up and attacks all these indefensible straw men like hashability and polymorphism – without ever addressing the fundamental raison d'etre for freezing, which is to stomp bugs repeatedly until they die. 🤕

[GregHilston]

@leycec I just wanted to add that your first reply to this thread is why I'll be switching to Beartypes over Pydantic. I honestly believe the examples you demonstrated here should be part of the most forward facing documentation. I spent some time trying to compare and contrast the two packages, and your comment here, did the best job of providing that information.

I wasn't sure where to provide this feedback, so if its inappropriate to do so here, I can remove this post

[leycec]

Fist bump! Thanks so much for the gracious feedback, Greg. Love your avatar, too. That's the most serious game-dev-casually-leaning-against-a-tree photo op I've ever seen. Never change that.

I honestly believe the examples you demonstrated here should be part of the most forward facing documentation.

You are unequivocally correct. Our documentation needs a jab in the arm from a qualified technical writer or documentation specialist... yet all we have is me. At the moment, the only public documentation on the subject is this @dataclass subsection in our sprawling Cheatsheet:

# ..................{              CLASSES ~ dataclass   }..................
# Import the requisite machinery. Note this requires Python ≥ 3.8.
from dataclasses import dataclass, InitVar

# User-defined dataclass. @beartype currently only type-checks the implicit
# __init__() method generated by @dataclass. Fields are type-checked *ONLY*
# at initialization time and thus *NOT* type-checked when reassigned to.
@beartype
@dataclass
class MyDataclass:
    # Annotate fields with PEP-compliant type hints.
    field_must_satisfy_builtin_type: InitVar[str]
    field_must_satisfy_pep604_union: str | None = None

    # Decorate explicit methods with @beartype as above.
    @beartype
    def __post_init__(self, field_must_satisfy_builtin_type: str) -> None:
        if self.field_must_satisfy_pep604_union is None:
            self.field_must_satisfy_pep604_union = (
                field_must_satisfy_builtin_type)

That's buried fairly far down, though. A dedicated human-readable section on integrating @dataclass + @beartype would go a long way to alleviating these usability concerns. Let's reopen this issue as a documentation request... so that I actually do this.

Thanks again, Greg – and thanks for digging deep into the wide world of @beartype. 🐻 🌳 🐻

[GregHilston]

@leycec its funny to me that you consider yourself not a technical writer, as I aspire to write as well as your comments here.

I admittedly have not even tried beartype yet, but once I've done so, I'll look into the pending issues on the project and see if there's any place I can help.

I'm a big fan of python, type hinting, and type checking with mypy, so it seems like data validation with beartype is a logical next step.

Thanks for updating this issue :)

[leycec]

I admittedly have not even tried beartype yet...

I'll look into the pending issues on the project and see if there's any place I can help.

That would be fantabulous. Since you name-drop technical writing, how do you feel about... Sphinx? </audience_gasp>

One of our more embarrassing issues that's been open since 0 A.B. (After Beartype) is the gradual refactoring of our inscrutable README.rst file into a cohesive suite of ReadTheDocs (RTD)-hosted documentation that no longer brings shame to @beartype. We've actually configured up a rudimentary Sphinx build complete with official RTD name-squatting. The groundwork's been laid... then no one bothered to build the house. 😓

Could be fun! Of course, that's what I tell all the volunteers.

...data validation with beartype is a logical next step.

@beartype: the final typing frontier.

These are the voyages of the type-checker beartype. It's infinitely long mission: to type-check strange new objects. To seek out new quality assurance and new PEPs. To boldly check what no code has checked before.

Thanks for updating this issue :)

Your faith is unsettling. Thank you for prodding me to do this. I swear this will be done. Someday. I swear.

[avicooper1]

To appease everyone, I'm currently finalizing a configuration API for (wait-for-it) beartype 0.10.0 to be released in a few more days I swear this by the frayed beard of Odin. I'm contemplating a hypothetical configuration option is_check_var_assignment=True for the next-next beartype 0.11.0 release cycle enabling users to type-check field reassignment on a @dataclass-by-@dataclass basis: e.g.,

from beartype import beartype, BeartypeConf
from dataclasses import dataclass

# Don't ask why this looks so awkward. Don't.
@beartype(conf=BeartypeConf(is_check_var_assignment=True))
@dataclass
class Point:
    x: int = 0
    y: int = 0

I'm curious if this was ever added – I've looked through the documentation and couldn't seem to find anything, but maybe I missed it. Any update on this would be super appreciated!

[leycec]

Hah, hah... ah. You're in luck! Actually, you're not in luck. This still doesn't exist. @leycec was bad and played video games all summer instead. You are now thinking:

"What part of this discussion makes me lucky?"

I was just getting to the lucky part. Rejoice, for these unfulfilling bullet points are better than nothing:

• Feature request [Feature Request] Deep O(1) type-checking of @dataclasses.dataclass fields on assignment #391 now officially tracks this! Admittedly, nothing has been done yet. @leycec continues playing video games. 🥳
• @GithubCamouflaged and I had a "deep" ^{...get it? hyuk-hyuk} discussion on this a few weeks ago. We now know exactly what needs to be done to draft a preliminary implementation of this.
• The high-level tl;dr is:
  • Defining and implementing support for a new BeartypeConf(is_check_pep557_assign: bool = False) configuration option probably is mostly trivial at this point.
  • Initially, this option will default to False because I don't trust myself to get this right for all possible use cases across all possible codebases that are not mine. So, PyTorch is what I am saying. Gods, let me please not blow up PyTorch again! 😭
  • Eventually, we'll globally flip this option to default to True. Various definitions of "Eventually" may be very long, indeed.

Basically, I failed to realize that everyone wanted me to fight Pydantic by implementing this. Instead, I devoted this summer to playing games going hard on @beartype's core mandate of rolling out deep O(1) type-checking for all of the remaining container types (e.g., collections, iterables, sets). Pretty much there, honestly. Couple more weeks before @beartype deeply type-checks the whole world. Would @leycec lie?

In hindsight, maybe I should've just fought Pydantic by implementing this.