[Guido] > >(b) I'm proposing an @abstractmethod, which sets its argument's > >__isabstractmethod__ attribute and then returns it, otherwise > >unchanged. Would this be good enough for you, or do you need @abstract > >to do more? My point is, I could rename mine to @abstract so that it > >would serve your purpose as well -- but only if it would serve.
On 4/23/07, Phillip J. Eby <[EMAIL PROTECTED]> wrote: > Assuming that: > > 1. If you call such a function, it will raise some error, like > NotImplementedError That would be up to the author of the function; they would have to explicitly raise NotImplementedError in the body. The ABC proposal allows meaningful abstract methods that can be called (only) via "super"; the use case for this is that the abstract method might be the one that decides which exception should be thrown (e.g. __getitem__ and __next__ do this), or perhaps it could provide a default implementation for certain types. (Potential example of the latter: Sequence.__getitem__() could raise IndexError when the argument is an Integer but handle the case where the argument is a slice instance, assuming there's a suitable factory which could be a designated class method.) > 2. It's a normal function object (i.e., can have its func_code repointed > later) Yes. > 3. The __isabstractmethod__ can be set back to False once there is other > code registered Yes. > Then yes, it's perfect. I guess it falls short. I'll stick with @abstractmethod, which rhymes with classmethod and staticmethod. You can have @abstract. -- --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
