This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author rhettinger
Recipients Aaron Gallagher, Ronny.Pfannschmidt, SwooshyCueb, THRlWiTi, Victor Milovanov, alex, asvetlov, christian.heimes, cvrebert, dabeaz, daniel.urban, eric.araujo, ethan.furman, habnabit, jcasale, josmiley, kenodegard, kynan, ncoghlan, piotr.dobrogost, rhettinger, simonzack, torsten, willrazen, 猫.黒
Date 2021-12-09.03:06:20
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1639019180.25.0.938805759603.issue14965@roundup.psfhosted.org>
In-reply-to
Content
-0 from me as well.  I don't think this is common or something that should be encouraged.  As Andrew points out, "del super().x" doesn't have an obvious meaning and it could be regarded as a code smell.

The OP's first example would be an unpleasant API to debug -- it exhibits tight coupling between the parent and child class, it has Liskov issues, and it has implicit forwarding and indirection through descriptors.  The tight coupling is especially problematic because Python's super() isn't guaranteed to call the parent class; rather, it can call a sibling class as determined by the MRO which cannot be known at the time the class is written.

Another thought is that super() is intentionally not a completely transparent proxy.  While an explicit call super().__getitem__(k) works, we've denied support for super()[k].  To me, "super().x = 10" and "del super().x" fall in the same category.

Looking at the OP's 

Fortunately, it doesn't seem to be a common need to use super() in a property setter or deleter to bypass the current class and call setter or deleter in a parent class property.  Arguably, this kind of tight coupling isn't good design.  The OP's first example would be an unpleasant API to debug.

FWIW,
History
Date User Action Args
2021-12-09 03:06:20rhettingersetrecipients: + rhettinger, ncoghlan, christian.heimes, habnabit, eric.araujo, alex, cvrebert, asvetlov, THRlWiTi, daniel.urban, dabeaz, torsten, ethan.furman, kynan, josmiley, Ronny.Pfannschmidt, piotr.dobrogost, 猫.黒, simonzack, jcasale, Aaron Gallagher, kenodegard, Victor Milovanov, willrazen, SwooshyCueb
2021-12-09 03:06:20rhettingersetmessageid: <1639019180.25.0.938805759603.issue14965@roundup.psfhosted.org>
2021-12-09 03:06:20rhettingerlinkissue14965 messages
2021-12-09 03:06:20rhettingercreate