Let's agree to disagree. I am getting tired from going around in circles about this.
On 4/24/07, Phillip J. Eby <[EMAIL PROTECTED]> wrote: > 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. > > -- --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
