Inheritance for native types is not supported
Default load_attr implementation (as used for all native types) doesn't take type inheritance (->bases_tuple) into account. I'm working on OrderedDict implementation, and it inherits most of its methods from dict, but adds few (well, 1) new method. Of course, this new method can be ignored, and old trick of putting the same .locals_dict to both types can be used. But I wanted to look into making truly inheritable methods, which requires setting custom .load_attr type method. And we already have implementation of this method which takes inheritance into account - for user classes/instances. But trying to use it, it assumes that object whose attr is being looked up is instance, so making it work with native objects means adding even more conditions to existing bunch of those (and which are already pretty mind-boggling). Another alternative is to make clean, "optimized" inheritance-friendly .load_attr for native types, but that means code duplication (and refactoring of existing code paths, factoring out functions, which means more stack usage, etc.)
Any thoughts?
Allow types to use both .attr and .locals_dict
This updates #6253. I must have accidentally closed it while moving branches around. I can't seem to re-open it now, so I'll open this one instead.
Right now, a type can have either a custom attr handler or a locals_dict. If it has both, attr gets called and locals_dict is not used.
With this PR, types can use the attr handler and locals_dict lookups cooperatively. This is useful for types that have both attributes and generic methods.
In essence, it allows you to add the following to your attr handler:
void custom_attribute_handler (mp_obj_t self_in, qstr attr, mp_obj_t *dest) {
// load, store and delete attribute
// Optional, made possible by this PR:
// No attribute found, continue lookup in locals dict.
dest[1] = MP_OBJ_SENTINEL;
}
For your use-case would you prefer #4969 or this here? Ultimately both of the patches could be useful for different things, they can both coexist.
I've been looking at this, and both can technically be achieved with just this updated PR. And since this is the smallest and most generic change, this one makes a bit more sense.