Typing conformance results

No changes detected ✅

I believe those changes on the conformance tests are "correct" in-so-far as those are instances of the case we want to catch here.

ecosystem-analyzer results

No diagnostic changes detected ✅

Large timing changes:

Full report with detailed diff (timing results)

@charliermarsh are you still interested in getting this over the line?

Yes sir, sorry, lost track.

I think the Expression diagnostic is correct:

  Expression (Try inherits from Result)

  - Result is decorated with @tagged_union(frozen=True, order=True)
  - tagged_union is marked with @dataclass_transform(), so ty recognizes it as a dataclass-like decorator
  - When order=True is passed, the class gets ordering methods
  - Try inherits from Result without defining its own comparison methods
  - True positive: At runtime, Try(Success(1)) < Result(Success(2)) would raise TypeError

Memory usage report

Summary

Significant changes

Charlie, sorry for the delay here. This is still low prio, and more complicated than it looks. Working on it...

My current problem is that I think inheriting from order=True is basically never safe? That is, except for edge cases where you don't add new fields in the child class? Even something like this fails:

>>> @dataclass(order=True)
... class C:
...     x: int
...
>>> @dataclass(order=True)
... class D(C):
...     y: str
...
>>> C(1) < D(2, "a")
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: '<' not supported between instances of 'C' and 'D'

That means you can't safely use a D where a C is expected, and therefore this new rule here should flag the construction of D. Enforcing that would require us to emit this diagnostic in too many places, though. So I'm wondering if it's all that useful. Interested in @AlexWaygood's opinion, since you proposed this rule originally.

I'm fine to just close this and prioritize other work if you prefer, not a big deal and clearly more complicated than initially perceived.

My current problem is that I think inheriting from order=True is basically never safe? That is, except for edge cases where you don't add new fields in the child class?

Even cases where you don't add new fields in the child class are unsafe, I believe -- see the example in the original issue I wrote up!

Enforcing that would require us to emit this diagnostic in too many places, though.

Not sure I follow... you just think it would be so many diagnostics that it would be overwhelming for users? Maybe, but I'm not sure order=True is a very popular feature, and subclassing order=True dataclasses is even rarer. And there's a pretty simple solution to the diagnostic: just use functools.total_ordering instead of using order=True if you intend to subclass the dataclass. functools.total_ordering doesn't have the same issue. We could even add an autofix that makes the change for you in the future.

Enforcing that would require us to emit this diagnostic in too many places, though.

Not sure I follow... you just think it would be so many diagnostics that it would be overwhelming for users?

As you can see from the ecosystem report, some dataclass-transformer libraries set order_default=True, and so you would basically have to set order=False on your model to enable any sort of subclassing. So yes, I assume this would be quite disruptive? Maybe there's a reason that no other type checker has implemented a rule like this?

But I guess we could make that rule opt-in?

Ah I see. Sorry, I hadn't looked at the ecosystem report, and didn't consider the impact on third-party dataclass-transformer libraries.

Are we not able to distinguish between stdlib dataclasses and third-party libraries? Could we add that distinction? I'd be fine making this rule only apply to stdlib dataclasses.

We may need to add this distinction anyway, to fix issues like astral-sh/ty#3486, where third-party dataclass-transform libraries behave differently to stdlib dataclasses.

Are we not able to distinguish between stdlib dataclasses and third-party libraries? Could we add that distinction? I'd be fine making this rule only apply to stdlib dataclasses.

It's easy to distinguish between the two. In fact, the original version here only implemented the check for stdlib dataclasses, but I argued that we should treat dataclass transformers in the same way ("If dataclass_transform is applied to a class, dataclass-like semantics will be assumed [...]") 🙃

I'll leave it up to you to decide what we do here (I will make the changes accordingly):

• flag both stdlib dataclasses and transformers, but make the rule opt-in
• only flag stdlib dataclasses, keep the rule enabled by default
• do not implement this rule at all (after all, there's only a single ecosystem hit for stdlib dataclasses, IIRC)

only flag stdlib dataclasses, keep the rule enabled by default

I'm cool with this, though also cool with just closing for now and calling this a non-priority for stable.

I'd also go with

only flag stdlib dataclasses, keep the rule enabled by default

I think unfortunately it's pretty clear that third-party dataclass_transform libraries often differ from the stdlib dataclasses module in edge cases. So whereas we want to abide by this when it comes to synthesizing dataclass fields and methods, etc.:

If dataclass_transform is applied to a class, dataclass-like semantics will be assumed [...]"

...I'm less sure that we want to abide by that principle so strictly when it comes to things like "in this specific edge case, the stdlib dataclasses module is known to raise a TypeError, and we'll emit a diagnostic warning you about that" (which this feels closer to).