3 ms·

Subclassing in Python Redux

101 points by hprotagonist 5y ago

emddudley 5y ago
This is a great article. Many good thoughts on subtle design decisions that I think anyone writing Python should ponder from time to time.
- tejinderss 5y ago
  Another great article in similar vein https://eev.ee/blog/2013/03/03/the-controller-pattern-is-awful-and-other-oo-heresy/ https://eev.ee/blog/2013/03/03/the-controller-pattern-is-awf...
rgserious 5y ago
https://recallgavin2020.com/ https://recallgavin2020.com/
guenthert 5y ago
"Code sharing is a bad idea." What? He lost me there. While that fellow clearly knows a lot more about OOP than me, statements like that, which are not exactly self-evident and go against prior best practices ("don't repeat thyself") need to be justified, otherwise it just looks like just some other random dude's opinion piece.
- hynek 5y ago
  I thought that from context it was clear that it means “Code sharing _via subclassing_ is a bad idea.” which the whole previous section tried to establish. I have clarified the sentence.
  - echion 5y ago
    It's much clearer now, with your clarification. Thanks to you for the update, and to OP for the question.
  - deleted 5y ago
    [deleted]
neoncontrails 5y ago
I might have balked at some of this advice until a few days ago, when I tried to create an FHE-encrypted key/value store that could be used as a drop-in replacement for `dict`. As it turns out, subclassing `dict` is awkward — especially if you're actively trying to override __setitem__, or make the object serializable with `pickle` (the latter goal actually introduced me to a low-level dundermethod I hadn't come across before, and hope to never touch again: __reduce__, the evil stepfather of __getstate__ and __setstate__). I really wanted these instances to be indistinguishable from ordinary `dict` objects as far as interface goes, so it seemed like an optimal use-case for inheritance. But in hindsight it seems like the "composition over inheritance" principle is ushering me to stash k,v pairs in a dictionary attribute of an ordinary (non-subclassed) class object and simply define methods such as update, delete, __setitem__, etc., rather than inheriting them. I don't think that's unreasonable, but the bigger problem I see with that approach is has to do with type dispatching: what if a user of this class is checking whether an object is an instance of `dict` (or `typing.Mapping` for that matter)?
- hynek 5y ago
  I’m not 100% sure (and on my phone) but I think the idiomatic way would be to subclass https://docs.python.org/3/library/collections.abc.html#collections.abc.MutableMapping https://docs.python.org/3/library/collections.abc.html#colle...
  - hprotagonist 5y ago
    and even then, it's a faff and a half: https://treyhunner.com/2019/04/why-you-shouldnt-inherit-from-list-and-dict-in-python/ https://treyhunner.com/2019/04/why-you-shouldnt-inherit-from...
    - neoncontrails 5y ago
      > The UserDict class initializer makes a dictionary which it stores in self.data. All of the methods on this dictionary-like UserDict class wrap around this self.data dictionary. Incredible. This appears to be exactly the solution to my problem. Thanks! (And, if thunner happens to come across this: thanks, from a former TA of yours!)

101 points by hprotagonist 5y ago

This is a great article. Many good thoughts on subtle design decisions that I think anyone writing Python should ponder from time to time.

tejinderss 5y ago
Another great article in similar vein https://eev.ee/blog/2013/03/03/the-controller-pattern-is-awful-and-other-oo-heresy/ https://eev.ee/blog/2013/03/03/the-controller-pattern-is-awf...

rgserious 5y ago

https://recallgavin2020.com/ https://recallgavin2020.com/

guenthert 5y ago

"Code sharing is a bad idea." What? He lost me there. While that fellow clearly knows a lot more about OOP than me, statements like that, which are not exactly self-evident and go against prior best practices ("don't repeat thyself") need to be justified, otherwise it just looks like just some other random dude's opinion piece.

hynek 5y ago
I thought that from context it was clear that it means “Code sharing _via subclassing_ is a bad idea.” which the whole previous section tried to establish. I have clarified the sentence.
- echion 5y ago
  It's much clearer now, with your clarification. Thanks to you for the update, and to OP for the question.
- deleted 5y ago
  [deleted]

neoncontrails 5y ago

I might have balked at some of this advice until a few days ago, when I tried to create an FHE-encrypted key/value store that could be used as a drop-in replacement for `dict`. As it turns out, subclassing `dict` is awkward — especially if you're actively trying to override __setitem__, or make the object serializable with `pickle` (the latter goal actually introduced me to a low-level dundermethod I hadn't come across before, and hope to never touch again: __reduce__, the evil stepfather of __getstate__ and __setstate__). I really wanted these instances to be indistinguishable from ordinary `dict` objects as far as interface goes, so it seemed like an optimal use-case for inheritance. But in hindsight it seems like the "composition over inheritance" principle is ushering me to stash k,v pairs in a dictionary attribute of an ordinary (non-subclassed) class object and simply define methods such as update, delete, __setitem__, etc., rather than inheriting them. I don't think that's unreasonable, but the bigger problem I see with that approach is has to do with type dispatching: what if a user of this class is checking whether an object is an instance of `dict` (or `typing.Mapping` for that matter)?

hynek 5y ago
I’m not 100% sure (and on my phone) but I think the idiomatic way would be to subclass https://docs.python.org/3/library/collections.abc.html#collections.abc.MutableMapping https://docs.python.org/3/library/collections.abc.html#colle...
- hprotagonist 5y ago
  and even then, it's a faff and a half: https://treyhunner.com/2019/04/why-you-shouldnt-inherit-from-list-and-dict-in-python/ https://treyhunner.com/2019/04/why-you-shouldnt-inherit-from...
  - neoncontrails 5y ago
    > The UserDict class initializer makes a dictionary which it stores in self.data. All of the methods on this dictionary-like UserDict class wrap around this self.data dictionary. Incredible. This appears to be exactly the solution to my problem. Thanks! (And, if thunner happens to come across this: thanks, from a former TA of yours!)