[ty] diagnostic on overridden __setattr__ and __delattr__ in frozen dataclasses#21430
[ty] diagnostic on overridden __setattr__ and __delattr__ in frozen dataclasses#21430carljm merged 3 commits intoastral-sh:mainfrom
__setattr__ and __delattr__ in frozen dataclasses#21430Conversation
crates/ty_python_semantic/resources/mdtest/dataclasses/dataclasses.md
Outdated
Show resolved
Hide resolved
Typing conformance resultsNo changes detected ✅ |
|
dad0985 to
5c3f14a
Compare
5c3f14a to
3272ab1
Compare
b7e81c1 to
bcf0226
Compare
|
Thank you for your contribution. I did not have time to review this in detail yet. One question upfront: would it be reasonable to use the existing |
|
@sharkdp i am not sure - one thing that seems like it could be nice over time is to have better diagnostic info for this specific case (for example highlighting the i will defer to you though - does seem reasonable! |
|
I think it's better to have a different error code here. |
|
I think it would be good to give the error code a name that makes it clear it's specifically about dataclasses, though, which the documentation of the rule makes clear |
|
We may add similar rules in future for things you're not allowed to override on a tuple subclass. Would we want those to use the same rule as the dataclass case, or a distinct rule for tuples? That may influence how we name this rule. |
|
(Having said that, I think maybe a different rule, since the tuple case won't be things that raise at runtime, just things that could cause unsoundness. So it would be reasonable to want to disable the one rule but not the other; and they should maybe have different severities. So I think I'd support naming this rule in a dataclass-specific way.) |
bcf0226 to
d76d6ca
Compare
a576b6e to
7611878
Compare
|
@AlexWaygood took another stab at naming based on how i interpreted your and Carl's comments cc @carljm - i wasn't sure the best way to pull these comments over from #21820. i did refactor |
7611878 to
a1cdc0c
Compare
|
Thank you! Sorry for the back-and-forth on naming... maybe
|
a1cdc0c to
c6148aa
Compare
|
@AlexWaygood ah! thanks for clarifying. sounds good - done |
|
@thejchap sorry for the slow response time! We've been getting swamped since the beta and this got lost in my notifications. I would say don't worry about those comments for this PR, let's just get the functionality right, better to separate things when separable. Those comments are mostly about making sure we handle various kinds of dataclass-transforms correctly, and that's kind of orthogonal to this PR anyway. |
|
Sounds good - I think this is ready for re-review then - let me know if I'm missing anything! |
|
Thank you for your work on feature. Almost the entire team is out this week. It may take a few days before someone finds time to review your PR. Happy holidays. |
|
@MichaReiser thanks! Happy holidays |
6064263 to
6036d5a
Compare
|
@AlexWaygood @MichaReiser hi! Just wanted to check on this one - I had been interested in continuing down this road on the diagnostics for overridden comparison dunder methods on order=True dataclasses as well so was curious on any feedback on the direction in this PR |
|
Sorry, we still have a bit of a PR backlog from the Christmas holidays :-( I haven't forgotten about this PR and I promise we will get to it. I've been trying to munch through review of as many PRs as possible this week. |
|
Ah no worries! Thanks for the update |
6036d5a to
9e23d3d
Compare
carljm
left a comment
There was a problem hiding this comment.
Looks great! Sorry again for the really slow review, we definitely aim to do better than this. This PR just hit the exact wrong time frame with beta release and then holidays :)
Summary
astral-sh/ty#111
this pr adds an
invalid-dataclass-overridediagnostic when a custom__setattr__or__delattr__is defined on a dataclass wherefrozen=True(docs)Runtime exception
Diagnostic
Test Plan
attrsmypy primer diff looks to be a true positive - the other results have been unpredictable and have changed every time i pushed new code, even if the diagnostic logic didn't change...