Skip to content
This repository has been archived by the owner on Feb 26, 2024. It is now read-only.

Reconsider our use of __getattr__() hackery for method inheritance #281

Open
jmurty opened this issue Jul 27, 2017 · 0 comments
Open

Reconsider our use of __getattr__() hackery for method inheritance #281

jmurty opened this issue Jul 27, 2017 · 0 comments

Comments

@jmurty
Copy link
Contributor

jmurty commented Jul 27, 2017

We use the __getattr__() special method in a couple of places in GLAMkit to do something resembling method overriding, except calling some default method implementation if no other class overrides the method in the correct way (i.e. by defining the method on a subclass).

See examples in ListableMixin and EventBase.

This whole approach makes me nervous since it is hacking around Python's standard MRO class-inheritance method overriding behaviour for reasons that are not clear to me.

Sooner or later we are likely to be bitten hard by this unusual behaviour, beyond just the work-arounds I have already need for f0a5499 for example. Can we scrap these __getattr__() methods altogether?

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant