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

Type checking for dataclasses #161

Open
jsh9 opened this issue Oct 25, 2020 · 10 comments
Open

Type checking for dataclasses #161

jsh9 opened this issue Oct 25, 2020 · 10 comments

Comments

@jsh9
Copy link

jsh9 commented Oct 25, 2020

Hi, I'm wondering if there can be support for type checking dataclasses? Currently, when I put @typeguard.typechecked on top of a dataclass definition, no checking happens (unless I'm mistaken).

Thanks!

@svermeulen
Copy link

Here's what I'm doing for this case:

https://gist.github.com/svermeulen/8a6ad727113a6d07f78332152c1d33b2

@dblock
Copy link

dblock commented Sep 15, 2021

@svermeulen Your gist works! Want to PR this to this project? Can I PR it? It needs a license.

@svermeulen
Copy link

Feel free to PR it. I've added MIT license now

@idvorkin
Copy link

Did this get merged?

@agronholm
Copy link
Owner

No, and I'm not sure what approach I want to take with regards to checking class/instance variable assignments. I don't think I will add support in v3.0. Maybe in a later release.

@faph
Copy link

faph commented Mar 23, 2023

That's a shame. With typeguard 2 this used to work if I am not mistaken.

@agronholm
Copy link
Owner

It never did work with typeguard 2.

@dkamm
Copy link

dkamm commented Apr 26, 2023

Hi @agronholm - are you planning to support this in typeguard 4?

@agronholm
Copy link
Owner

Maybe in some follow-up minor release, but not the 4.0 release that is imminent.

@NicolasNarvaez
Copy link

In the case when one doesn't know what approach use to a solution like this, the best is to be flexible and give a temporary solution that works for the simpler and most fundamental case, that we know most devs would use, than to not give an alternative at all. I'm sure most of use are doing almost the same.
What is the issue with the proposed solution?, why not just split the logic for class, and instances, and weirder cases?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

8 participants