Sure - thanks - I did not even consider the descriptor mechanism, as I got focused in getting the equivalent from the __class__ cell inside the decorator code.
And of course, now there is the "__init_subclass__" mechanism - a mixin version using that was as straight forward as it can be as well. On 31 January 2017 at 17:33, Ned Batchelder <n...@nedbatchelder.com> wrote: > On 1/31/17 2:13 AM, Roberto Martínez wrote: >> Hi, >> >> I find this type of code quite often: >> >> class MyOverridedClass(MyBaseClass): >> def mymethod(self, foo, **kwargs): >> # Do something >> return super().mymethod(**kwargs) >> >> What about creating a decorator to call super() after/before the >> overrided method? Something like that: >> >> class MyOverridedClass(MyBaseClass): >> @extendsuper >> def mymethod(self, foo): >> # Do something >> >> Sorry if this has already been proposed, I have not found anything >> similar in the list. > With all of the possible details that need to be covered (before/after, > what args to pass along, what to do with the return value), this doesn't > seem like a good idea to me. The most common use of super is in > __init__, where the value should not be returned, and the example given > here returns the value, so right off the bat, the example is at odds > with common usage. > > The super call is just one line, and the decorator would be one line, so > there's no savings, no improvement to expressivitiy, and a loss of > clarity: -1. > > --Ned. > _______________________________________________ > Python-ideas mailing list > Python-ideas@python.org > https://mail.python.org/mailman/listinfo/python-ideas > Code of Conduct: http://python.org/psf/codeofconduct/ _______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
