On 4/24/07, Phillip J. Eby <[EMAIL PROTECTED]> wrote:
> At 09:25 PM 4/23/2007 -0700, Guido van Rossum wrote:
> >I don't see the point of having an abstract class without abstract methods.
Phillip is used to writing classes with (unbased) mutally recursive
functions. Concrete example:
class Eq(object):
def __eq__(self, other): return not self.__ne__(other)
def __ne__(self, other): return not self.__eq__(other)
There isn't a single method that needs to be overridden, so he doesn't
want to mark either method as abstract. You need to override one of
them, so he would like to mark the class abstract.
> Mine (courtesy of other languages) is, "a method without an
> implementation". Yours appears to be "a method that must be
> overridden".
+ " or extended"
I still call it overriding, but Guido sometimes distinguishes the two
-- and methods which must be extended are important cooperative super
calls.
> >... (b) to provide an end point for cooperative-MI-style code.
> But "b", as far as I can tell, doesn't have anything to do with
> abstractness as I understand it. If there's a useful end-point, why does
> it need to be abstract?
Usefor for cooperative-MI-style might mean "useful to the programmer,
who doesn't need to add boilerplate catching the exception just in
case his class was the last *concrete* class"
Though in this case, I think he is also referring to partial implementations.
Look at Sequence.__getitem__ in
http://svn.python.org/view/sandbox/trunk/abc/abc.py?rev=54894&view=markup
An implementation does need to override the method, but the override
could just be an extension that handles only integer indices, and
defers slice indices.
-jJ
_______________________________________________
Python-3000 mailing list
Python-3000@python.org
http://mail.python.org/mailman/listinfo/python-3000
Unsubscribe:
http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
