On 4/26/07, Bill Janssen <[EMAIL PROTECTED]> wrote: [Guido] > > But it makes sense in some cases to insist that someone who goes > > through the trouble of inheriting from an ABC gets an error if they > > forget to implement one of the methods that are deemed 'essential' to > > that ABC. > > This is the problem with abstract methods. What should happen is that > the default method (the one defined in the ABC class) gets called. > Otherwise you're back in the morass of Java types, without effective > mixin capability. In Python, we need to be able to define an abstract > class with real implementation methods -- a class that both defines an > interface, and provides an implementation. That means that anyone > providing a subclass need only implement the methods that they > override. > > Now, we can still have a way of marking the methods of an ABC as being > "not implemented", which would in fact force the subclass designer to > implement them. But this concept should be carefully separated from > the concept of "this method is part of the interface defined by this > class".
Yeah. I like @abstractmethod to mean "not implemented" (except perhaps as an end point for cooperative super calls). For the latter concept, I propose that all methods present in an apparent ABC are considered part of the interface, unless their name starts with a single underscore (the latter should be considered implementation details, or perhaps definitional details). -- --Guido van Rossum (home page: http://www.python.org/~guido/) _______________________________________________ Python-3000 mailing list [email protected] http://mail.python.org/mailman/listinfo/python-3000 Unsubscribe: http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
