Open Julian opened 6 months ago
OK I suppose I should have at least checked whether adding final()
to things dynamically actually works, which a first try does not, at least with pyright
. I haven't had coffee yet this morning so this all might be nonsense.
I think final and frozen are a bit different concepts, but the bigger question is if this is achievable with dataclass transforms at all?
Yeah sorry I forgot to come back to this after but it seemed like the answer was unfortunately "no".
I am filing the below not really having through details, though I at least don't see this mentioned in any other issue, hence splatting it out :). Spicy takes I'm sure coming below as I'm sure part of this rests on how much each of us tolerates inheritance.
Should
attrs
have a way to apply typing.final to its classes so that they're easier to mark as "don't subclass"? E.g. afinal=
argument tofrozen
/define
/mutable
?Obviously stacking the two decorators works, so the motivation I guess for me personally is just "I always want
final
for basically any class I expose", so ifattrs
had this it's one less thing to forget. What I do now is usually things at runtime, which don't use final() at all, but given I just realized I should probably addfinal()
too so that users who do rely on their type checkers see a warning, that made me wonder whether that half is something general enough to be here.If it were an argument to
define
, defaulting toTrue
obviously breaks backwards compatibility. Perhaps doing it forfrozen
at least is justifiable? Or at least desirable with a deprecation warning for subclassing in the interim?Any thoughts on how reasonable that sounds?