[Python-3000] Generic function PEP won't make it in time

[Guido van Rossum]

On 4/23/07, Talin <talin at acm.org> wrote:
> I think I am in (weak) agreement with Phillip here. In every language
> that I am familiar with, the adjective "abstract" when applied to a
> method implies two things: (1) that the method does not have a body, and
> (2) the method must be implemented by a subclass if that subclass is
> able to be instantiated. In fact, (2) is merely a consequence of (1),
> when combined with the additional constraint that no instantiated class
> can have methods with no body.
>
> However, I think what is going on is that you're using the word
> "abstract" in a slightly difference sense. Normally, an abstract method
> provides merely an interface, in other words it defines the method name,
> argument types, and return type of a method - and nothing more.
>
> What you're doing, I think, is saying that an abstract method provides
> all those things, and in addition it provides a kind of sketch or
> outline of what the functionality ought to be. I don't have a problem
> with that part so much.

Right. That's was the original goal.

> But in addition there is a sense that you also want these methods to be
> useful helper functions for base classes to call, but you don't want
> them to be called directly. In languages such as Java and C++, this is
> what "protected" is for - methods that aren't available to the outside
> world, but which can be called by subclasses.

But Python doesn't have protected, and isn't about to get it.

> So it seems to me -- at least from the standpoint of someone steeped in
> the mindset of Java / C++ / C# et al -- that you are conflating
> "abstract" and "protected".
>
> In what is considered "good style" for such languages, protected helper
> methods ought to have different names than the methods which invoke
> them.

Unfortunately then the ABC would need to invent names for those helpers.

> So for example, you might have the following:
>
>     /// Abstract base class for hashable object
>     class Hashable {
>     public:
>        /// Declare abstract hash method
>        virtual int GetHash() const = 0;
>
>     protected:
>        /// Protected helper method
>        int DefaultHashFunc() { return 0; }
>     };
>
>     // A concrete class derived from hashable
>     class MyConcreteClass : public Hashable {
>     public:
>        /// Declare abstract hash method
>        virtual int GetHash() const { return DefaultHashFunc(); }
>     };
>
> Granted, in this particular case the decision to provide a helper
> function is rather odd. Why go through the trouble of defining
> DefaultHash() in the base class that simply returns 0, when any
> non-trivial subclass will provide a real implementation of GetHash()
> instead of merely forwarding the call to DefaultHash()?

Hashable.__hash__ is probably not the best example of the idea; its
implementation is valid but useless, so it really serves more as a
"sketch or outline of the functionality".

> But the solution isn't to give Hashable::GetHash() a body. From a C++
> programmer's view, there's only two choices: Either Hashable::GetHash()
> is abstract, or it's not. If it's abstract, then every subclass is
> required to re-implement it, and giving it a body has no purpose
> whatsoever; If it's not, then subclasses are allowed to default to its
> implementation.

I'm not afraid of breaking new ground. Since the fact of the matter is
that we can't prevent abstract methods from having a body (that would
require syntactic support for abstract methods which is out of scope
here) we might as well make good use of the body.

There's also the use case of providing an end-point for cooperative
super-calls, which I've brought up repeatedly but which nobody seems
to pick up. Perhaps because cooperative super-calls are not supported
by either Java or C++. But they do exist in other languages (Lisp, and
the C++ extension described in "Putting Metaclasses to Work: A New
Dimension in Object-Oriented Programming", by Ira R. Forman and Scott
H. Danforth (which formed the basis of much of my thinking on
metaclasses, and which I reference in "Unifying types and classes in
Python 2.2": http://www.python.org/download/releases/2.2.3/descrintro/).

-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)