-
-
Notifications
You must be signed in to change notification settings - Fork 358
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
Add support for marking classes typing.final
#1247
Comments
OK I suppose I should have at least checked whether adding |
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?
The text was updated successfully, but these errors were encountered: