This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author rhettinger
Recipients peleg2, python-dev, rhettinger
Date 2021-02-10.21:37:12
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1612993032.92.0.996499380965.issue43178@roundup.psfhosted.org>
In-reply-to
Content
I prefer to keep the code as-is.  It is microscopically faster than than just inheriting the methods, but more importantly it makes it easier to read the code and know that it is correct.  We're instructing people to override all four methods when subclassing and we don't make any promises about how the parent method is implemented.  At this point, the implementations happen to be the same, but that isn't guaranteed.  We could at some point change the implementation of the parent class method and wouldn't want the subclasses to break.

So, let's keep the loose coupling, the self-contained code that follows the rules, code that is slightly faster, and code that is easy to read.

Thank you for the suggestion, but this micro-factoring doesn't make us better off.
History
Date User Action Args
2021-02-10 21:37:12rhettingersetrecipients: + rhettinger, python-dev, peleg2
2021-02-10 21:37:12rhettingersetmessageid: <1612993032.92.0.996499380965.issue43178@roundup.psfhosted.org>
2021-02-10 21:37:12rhettingerlinkissue43178 messages
2021-02-10 21:37:12rhettingercreate