-
-
Notifications
You must be signed in to change notification settings - Fork 383
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
Calling super.__init__ before attrs __init__ (or, __attrs_pre_init__) #725
Comments
Thank you for being a sponsor, happy to boot! As stated in #393 (comment), I think it would be overall a nicer design to allow for telling That said I'm somewhat OK with doing |
I would like to notice that while |
IOW types alone make it worth having both in any case? |
Yes, my intention was to move current
|
Ah I've missed this message! While I want it to do that conceptually, I don't want to have that extra method and and method call on all classes. |
@indigoviolet FYI that the approach I highlighted here works great as a DIY I'm looking to open source my code as a Pytorch configuration library built on attrs in the near future. But in the meantime, you should try the code I linked above. |
@hynek : See #750 for Just so I understand your thought process, earlier I thought you preferred the
|
I think But in practice my gut feeling is that pre_init is gonna see more practical applications. But I might be wrong. There’s a sizable user base of attrs that chose us specifically because we don’t force types on anyone and once they’re out of the equation the upsides of pre_init wane. Am I somewhat coherent?. |
Hi,
(Thanks for your work on attrs, it's fantastic, I'm a happy sponsor)
I'm subclassing
pytorch
'snn.Module
and it has some "magic" treatment of members that are of certain types, which boils down to it requiring invokingsuper().__init__()
before assigning instance variables, so I can't just use__attrs_post_init__
for this.I've read #695 (comment), #640 (comment), #167 etc and I'm generally in agreement about composition vs. inheritance, but I'd love to be able to use the convenience of attrs in this situation: a library class that I need to subclass but have no control over.
Naively, it seems to me that this could be satisfied by having an
__attrs_pre_init__
hook that receives all the constructor arguments. I assume you have considered this - would you be open to a PR adding it (it seems relatively straightforward following the code for__attrs_post_init__
)?The text was updated successfully, but these errors were encountered: