Why does this need to be used with wx subclasses?

WX Python 3 used swig to wrap WX C++ classes, WX Python Phoenix uses sip.

>>> type(wx.Dialog)
<type 'sip.wrappertype'>

If we don't create SIPABCMeta and just assign ABCMeta as meta class to SettingsDialog or SettingsPanel, NVDA will fail to start due to a meta class conflict, since ABCMeta and wx.siplib.wrappertype are unrelated to each other. You can't assign multiple meta classes to a class.

what about abstract set? If set and get need different patterns, perhaps _abstract_get_x and _abstract_set_x

In the current implementation, you mark an entire property as abstract. Note that not the methods, but the property itself is considered abstract, which is also the case when using abc.abstractproperty.

This is clearer to me now thanks to your other explanation. However, I'm concerned that its not so obvious from the syntax used to mark the property as abstract. Essentially what _abstract_x is saying is "use magic to declare that this class must have a property called x but its implementation is left to subclasses". It makes me wonder though.. is there any point in declaring _get_x and _set_x methods. This makes x look very much NOT abstract.

This looks odd, but is behavior defined by Python. It might be helpful to read the docs for the Abstract module

In short: an abstract method or or property doesn't mean that the method or property should be left unimplemented, since a sub class can call the method or get the property of the abstract base class.

Also note from the Python docs:

C++ programmers should note that Python’s virtual base class concept is not the same as C++’s.

Does this help?

In short: an abstract method or or property doesn't mean that the method or property should be left unimplemented, since a sub-class can call the method or get the property of the abstract base class.

But it doesn't have to be implemented in the base class, right? Except there is the note in the AutoPropertyObject about set overriding the property.

C++ programmers should note that Python’s virtual base class concept is not the same as C++’s.

Hahaha this would help a lot more if the differences were described.

I think I must be missing the point when it comes to properties. I assume the goal is: allow a base class to declare that a certain property must exist in the construction of a subclass, without necessarily providing the implementation for that property in the base class?

@feerrenrut commented on 7 aug. 2018 10:57 CEST:

Note that within AutoPropertyObject, there is no such thing as a read only property. When someone only implements _get_x, setting x will override the property completely.

It would be nice if we could find a way to catch the situation where _get_x is provided but not _set_x. Is there is a situation in which this behaviour is desirable?

There are actually quite a lot of cases where _get_x is declared and _set_x is not. See displayModel.DisplayModelTextInfo, _get_backgroundSelectionColor and _get_foregroundSelectionColor. These cases perfectly explain the use of this functionality, namely fetching a value the first time the property is retrieved.

What do you actually want to catch exactly? I'd rather catch cases where set is implemented and get isn't, because those make less sense to me.

Either decorating _get_x or _set_x with abstractmethod is dangerous as I noted above

But if it's not abstract, then the base class should be providing it:

class Test(AutoPropertyObject):
...

Your example looks nice, but I"m afraid that it doesn't work as you expect it to work, or I"m just not getting what you're trying to point out.

class Test(AutoPropertyObject):

	def _get_x(self):
		return 42

	def _set_x(self, val):
		print("Magic setter")

class Subtest(Test):
	x = 84

test = Test()
print(test.x)
42
test.x = "random"
"Magic setter"
print(test.x)
42

subtest = Subtest()
# Note that setting x on the subclass wil override x completely, so it will abandon both the getter and the setter. Therefore, overriding x when it is marked as abstract should make it no longer abstract?.
print(subtest.x)
84
# Note that this does no longer print anything.
subtest.x = "random"
print(subtest.x)
84

I think I can live with it if we decide to do the abstraction at the method level, it might look easier to understand.

Thinking about the example I gave above, I guess that doing abstraction at the method level will also cause confusion anyway..

What do you actually want to catch exactly?

In the case of displayModel.DisplayModelTextInfo, someone accidentally sets backgroundSelectionColor overriding the property entirely, meaning that the implementation for _get_backgroundSelectionColor no longer gets called. Perhaps this is intentional, but it means that there is a disconnect between the set value and the underlying object.

I'm just not getting what you're trying to point out.

I just had a play with this in the python console. I wasn't aware that the autoProperty would not fall back to the base classes definition (say of _set_x). Eg given:

class base(AutoProperty):
    def _get_x(self):
        return 42

    def _set_x(self, val):
        print("in base _set_x")

class sub(base):
    def _get_x(self):
        return 84

I expected:

b = base()
b.x # returns 42
b.x = "hello" # prints "in base _set_x"
b.x # returns 42
s = sub()
s.x # returns 84
s.x = "hello" # expected it to print "in base _set_x", actually does not.
s.x # expected to return 84, but returns "hello"

Are you aware of a reason for this behaviour? It seems to break the polymorphic behaviour that I would expect. I suppose it could be that I'm tying the interface of the property to the interface of the class, and instead the interface of the property (and it's type) should not be considered part of the class that holds it, merely the existence of a property called x

Woops, I pressed reply too quickly.

@feerrenrut commented on 8 aug. 2018 04:20 CEST:

Are you aware of a reason for this behaviour?

Yes, see this code snipped from baseObject.

			if not g:
				# There's a setter or deleter, but no getter.
				# This means it could be in one of the base classes.
				for base in bases:
					g = getattr(base,'_get_%s'%x,None)
					if g:
						break

I agree that it is confusing that AutoPropertyType digs in base classes to find an already set getter, but it does not do this for setters and deleters. I didn't care much, as it has been this way since ages, at least since 2009. However, it is certainly a bit unclear as of what the initial ittentions were when @jcsteh wrote this.

@feerrenrut: Do you want me to change anything in this behaviour, or do you have any other concerns?

No, I think it's ok for now.

Why can't this also just use @abstractmethod?

Because that would mark _get_bookmark as an abstract method. Imagine the following subclass:

class Test(textInfos.TextInfo):
    Bookmark = None

Here, bookmark is overridden at the class level and therefore should no longer be abstract. However, when we mark _get_bookmark as an abstract method, the subclass wouldn't instantiate because _get_bookmark is still abstract. To summarize, using abstractmethod for magic get and set methods will make it impossible to override a property at the subclass by means of the method explained above.

I hope this clears up things a little bit.

I think this is part of what threw me off. The property is considered implemented if either of _get_x or _set_x are implemented? Another concern, is how does the base class declare that the intended interface is "read-only" for the property.

The property is considered implemented if either of _get_x or _set_x are implemented?

Yes, either set, get or del.

This would be the pure pythonic way

class foo(object):
    __metaclass__ = ABCMeta

    @abstractproperty
    def bar(self):
        return 42

class foo2(foo):

    @property
    def bar(self):
        return super(foo2, self).bar*2

baseObject will behave like abstractproperty if _abstract_x is True, else it behaves like property.

Another concern, is how does the base class declare that the intended interface is "read-only" for the property.

Could you elaborate? I assume you mean somehting like this:

class foo(object):
	@property
	def bar(self):
		return 42

inst=foo()
inst.bar=42*2

Traceback (most recent call last):
  File "<console>", line 1, in <module>
AttributeError: can't set attribute

From the doc string of AutoPropertyObject:

If there is a _get_x but no _set_x then setting x will override the property completely.

So indeed, this differs from how python properties behave normally.

Would applying deorgan's law make this more clear to a human?
if g and (not s and not d)
turns into
if g and not (s or d)
or in other words, if it's a getter, and neither a setter or deleter

Would it be equivelent to instead do a set intersection with newAbstratProps & abstract eleminating oldAbstractprops?

You mean, just self.__abstractmethods__ = (self.__abstractmethods__&newAbstractProps) . That would also eliminate abstract methods that aren't abstract properties at all.

Is the case where this occurs only within subclasses?

Yes, as it deals with removing the abstract properties from _-abstractmethods that are no longer abstract.