GNOME Bugzilla – Bug 439531
Unable to define instance variables in Accessible
Last modified: 2019-03-27 20:11:15 UTC
I'm starting work on porting dogtail to pyatspi from pyspi. The way I'm currently doing the port is by converting dogtail.tree.Node into another mixin for Accessibility.Accessible, and doing the same for most of the other classes in dogtail.tree. The use of __slots__ in _AccessibleMixin means that I can't define any instance variables. Node currently uses (I'm pretty sure only) one instance variable, called debugName, which is a string that describes how the Accessible was "found" - e.g. "child of foo named bar". It makes for very nice logfiles in case something blows up. I'm currently just patching pyatspi to add 'debugName' to __slots__, but I don't feel it's the right way to do this. Pete suggested adding an addSlot method somewhere, which would work if it was called by dogtail (or others) before any Accessibles were instantiated. But what about just adding '__dict__' to slots, so that instance variables could be added without any special calls beforehand?
We could remove __slots__ entirely so the regular __dict__ is instantiated for accessibles. But this introduces extra overhead of a dictionary per object that pyorbit was working to minimize in the first place by making __slots__ = (). I'm not sure we want to force that overhead on all ATs by default. How are you doing your mixins? If you can give me an example of what you're doing, maybe we can find a better solution.
Zack, Instead of allowing a __dict__ field to be created and initialized to {} for all accessible objects, what if we defined a slot for "user_data" which you could initialize to whatever you wanted? I'm hesitant to change the default behavior from __slots__ = () to __dict__ = {} on all accessibles because of the extra overhead it introduces. Can you work with user_data?
Created attachment 88803 [details] [review] user_data
Peter, It looks like that will work just fine; I've discovered another instance variable that dogtail currently uses (but may not need to after the port, I need to rethink some things), so for now I've just made debugName a property that refers to user_data['debugName'] - I made it a dict - and handles the cases of user_data not being initialized, etc. That way I can add whatever I need to it later. Thanks!
Hey Zack, Didn't see your response until today. I'm checking in the user_data patch. If it turns out that it doesn't fulfill all your needs, feel free to reopen this bug later.