super() objects allow access to inherited properties fget() but not fset() or fdel(), resulting in unexpected behavior.

Today on pydev thread 'Property inheritance in Python' GvR said "I
don't see the need for a Python-Ideas detour. It seems worth fixing"

>>> class BaseProp(object):
...     @property
...     def p(self):
...         return self._p
...     @p.setter
...     def p(self, value):
...         self._p = value
>>> class DerivedProp(BaseProp):
...     @property
...     def p(self):
...         return super(DerivedProp, self).p * 2
...     @p.setter
...     def p(self, value):
...         super(DerivedProp, self).p = value / 2
>>> d = DerivedProp()
>>> d._p = 21
>>> d.p
42
>>> d.p = 50
Traceback (most recent call last):
   ...
AttributeError: 'super' object has no attribute 'p'

>>> class DerivedProp(BaseProp):
...     @property
...     def p(self):
...         return super(DerivedProp, self).p * 2
...     @p.setter
...     def p(self, value):
...         BaseProp.p.__set__(self,value / 2)

I'm attaching a patch implementing super.__setattr__ (and __delattr__).

The implementation in the patch only works, if super can find a data descriptor in the MRO, otherwise it throws an AttributeError. As it can be seen in the tests, in some cases this may result in counter-intuitive behaviour. But I wasn't able to find another behaviour, that is consistent with both super.__getattr__ and normal __setattr__ semantics.

I stumbled across this omission as well in 2010 and brought this up on python-dev:

http://mail.python.org/pipermail/python-dev/2010-April/099672.html

There were no replies, but perhaps my post adds a bit of information and also there is another patch linked from there. I attached my patch from 2010 for reference.

I'm -0 for proposed changes, these changes reduce code readability from my perspective.
I think better to use existing approach: explicitly specify what do you want to do with overloaded properties.

I'm not a python dev, but would you say

super(self.__class__, self.__class__).x.fset(self, value)

is more readable than

super().x = value

I would say

@x.deleter
def x(self):
    del super().x

confuses me a bit. 
But I'm only -0, let's see other developers for their opinions.

Just as a note, there is a distinct possibility that a "property" in a superclass could be some other kind of descriptor object that's not a property.  To handle that case, the solution of

super(self.__class__, self.__class__).x.fset(self, value)

would actually have to be rewritten as

super(self.__class__, self.__class__).x.__set__(self, value)

That said, I agree it would be nice to have a simplified means of accomplishing this.