At 10:50 AM 4/24/2007 -0700, Guido van Rossum wrote: >On 4/24/07, Phillip J. Eby <[EMAIL PROTECTED]> wrote: >>Mine (courtesy of other languages) is, "a method without an >>implementation". Yours appears to be "a method that must be >>overridden". > >That's a very subtle distinction, since the *goal* in other languages >is certainly to force it to be overridden.
But this just goes right back around to the original point... if you *have* an implementation, you don't really *need* to force it to be overridden. Or do you? As far as I can tell, you still haven't said what the point of *forcing* somebody to override perfectly usable methods is. You've merely said you don't see the point of inheriting or using them directly, but that's not the same thing as a rationale for *forcing* them not to. >Being a useful end-point and being abstract >are separate concepts. They are intertwined only because IMO >abstract-ness shouldn't prevent something from being a useful >end-point. But that's the very definition of "abstract" -- i.e., that it's *not* useful. >The only practical concrete use I see of these abstract classes would >be to have a handy "empty sequence/set/mapping/iterator/etc." >implementation. Since an empty list/set/dict/etc. serves just as well >for that purpose I don't think this is a strong use case. That's certainly true for the Python-supplied ABCs, but it's not so for many other use cases. I frequently write base classes that have various default implementations, combined with a few methods that have to be overridden. On the other hand, specifying which methods >What I'm *trying* to do with the @abstractmethod decorator is telling >potential implementors of these classes: the minimum set of operations >you need to provide in order to be an X is this one (or these two or >three) methods (the ones that have the @abstractmethod decorator). Then let's call it @required or @requiredmethod, and all is well. :) I've just been trying to get clarity on your intent, so I could suggest a name that reflects that intent. At this point, it seems clear your intent is to say, "this method is required in a subclass, even if there's an implementation here". So let's have a name that reflects that intention. (I still don't see the point of marking a method as required if it has an actual implementation, since to my way of thinking there is no harm in someone *not* overriding it. They simply don't get as rich of a behavior in that case. But that's a separate issue.) >>And what *is* the purpose of being required to provide an implementation, >>if a useful one exists? This is the bit I guess I'm still missing. > >What is the point of claiming to be a Sequence *without* overriding >__getitem__? I didn't say there was a point to that. However, as Jim Jewett pointed out, you can have mutually recursive default implementations of a protocol, and probably at least *one* of the methods needs to be overridden. Really, the patterns of what needs to be overridden in subclasses is complex enough that we don't really want to get into a bunch of ways to specify how those things should be overridden. That's why I don't see the "make sure you override everything" testing as being all that useful; it seems too much like adding empty methods and extra "try" blocks in Java just to get your code past the compiler. _______________________________________________ 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
