Re: [Python-ideas] Please consider adding an overrideable flag to abstractmethod
reposting -- things go to heck when posts are forwarded through google groups :-( -CHB On Sun, Feb 17, 2019 at 8:32 AM Christopher Barker wrote: > On Sun, Feb 17, 2019 at 2:32 AM Neil Girdhar > wrote: > >> Alternatively, the need for an overriding implementation to call super >> could be marked by a different decorator. >> > > Looking back on the old "Super considered [Harmful | Super]" discussions, > it was clear that the fact that a class hierarchy uses super() is part if > its API, and: > > and every occurrence of the method needs to use super() > > So +1 on having an explicit way to specify that super should be used in > subclasses, rather than having to look in documentation or the source code > to figure that out. > > -CHB > -- Christopher Barker, PhD Python Language Consulting - Teaching - Scientific Software Development - Desktop GUI and Web Development - wxPython, numpy, scipy, Cython ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-ideas] Please consider adding an overrideable flag to abstractmethod
Alternatively, the need for an overriding implementation to call super could be marked by a different decorator. This would allow linters to check that subclasses call super when they should, which is a very useful check in my opinion. Such a decorator could be called "@overrideable", and could be exposed in abc. When used in combination with @abstractmethod, it could have the above behavior. On Sunday, February 17, 2019 at 5:28:49 AM UTC-5, Neil Girdhar wrote: > > Marking a method M declared in C with abstractmethod indicates that M > needs to be *implemented* in any subclass D of C for D to be instantiated. > > We usually think of overriding a method N to mean replacing one > implementation in some class E with another in some subclass of E, F. > Often, the subclass implementation calls super to add behavior rather than > replace it. > > I think that this concept of *implementing* is different than *overriding*. > > However, abstract classes can have reasonable definition, and should > sometimes be overridden in the sense that subclasses should call super. > For example, when inheriting from AbstractContextManager, you need to > *override* the abstractmethod (!) __exit__, and if you want your class to > work polymorphically, you should call super. > > This is extremely weird. Understandably, the pylint people are confused > by it (https://github.com/PyCQA/pylint/issues/1594) and raise bad > warnings. > > It also makes it impossible for me to raise warnings in my ipromise ( > https://github.com/NeilGirdhar/ipromise) project. See, for example, > https://github.com/NeilGirdhar/ipromise/blob/master/ipromise/test/test_overrides.py > > classes Y and W, which ought to raise, but that would raise on reasonable > code. > > My suggestion is to add a rarely used flag to abstractmethod: > > class AbstractContextManager: > @abstractmethod(overrideable=True) > def __exit__(self, exc_type, exc_value, traceback): > pass > > This would set a flag on the method like __abstractmethod_overrideable__, > which could be checked by ipromise's @overrides decorator, pylint's call > check, and anyone else that wants to know that a method should be > overridden. > > Best, > > Neil > ___ 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] Please consider adding an overrideable flag to abstractmethod
Marking a method M declared in C with abstractmethod indicates that M needs to be *implemented* in any subclass D of C for D to be instantiated. We usually think of overriding a method N to mean replacing one implementation in some class E with another in some subclass of E, F. Often, the subclass implementation calls super to add behavior rather than replace it. I think that this concept of *implementing* is different than *overriding*. However, abstract classes can have reasonable definition, and should sometimes be overridden in the sense that subclasses should call super. For example, when inheriting from AbstractContextManager, you need to *override* the abstractmethod (!) __exit__, and if you want your class to work polymorphically, you should call super. This is extremely weird. Understandably, the pylint people are confused by it (https://github.com/PyCQA/pylint/issues/1594) and raise bad warnings. It also makes it impossible for me to raise warnings in my ipromise (https://github.com/NeilGirdhar/ipromise) project. See, for example, https://github.com/NeilGirdhar/ipromise/blob/master/ipromise/test/test_overrides.py classes Y and W, which ought to raise, but that would raise on reasonable code. My suggestion is to add a rarely used flag to abstractmethod: class AbstractContextManager: @abstractmethod(overrideable=True) def __exit__(self, exc_type, exc_value, traceback): pass This would set a flag on the method like __abstractmethod_overrideable__, which could be checked by ipromise's @overrides decorator, pylint's call check, and anyone else that wants to know that a method should be overridden. Best, Neil ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
