[Types-sig] Re: PRE-PROPOSAL: Python Interfaces

Tim Peters tim_one@email.msn.com
Tue, 24 Nov 1998 18:18:38 -0500


[Barry A. Warsaw]
> ...
> I want a different kind of error to get thrown when a class
> says it implements a particular interface, but in fact neglects
> to.  If I have a class List that claims to implement interface
> Stack, but in fact does not provide an implementation of pop()
> or push(), I don't want an AttributeError when I call one of
> those methods on an instance of List.  I want something like
> NotImplementedError.  I think this important enough to guarantee
> in language spec.
>
> Tim also wants to allow implementation in an interface
> definition, because some methods can be defined solely in terms
> of other methods in the interface.  That seems fine to me.

As we discussed on the egroups version of this, if interfaces allow
supplying impementation, then

    from InterfaceSupport import deferred

    class Stack(Interface):
        def push(self, thing): deferred()
        etc

would make everyone who *claims* to implement Stack pick up the (presumably
error-raising) Stack.push "deferred()" implementation if they don't supply
their own (or inherit some other) real implementation of push.

> ...
> I think the same approach will have to be taken with the core
> w.r.t. interfaces.  Keep the set of interfaces defined by the
> core as shallow and small as possible, but provide enough rich
> mechanisms so that applications can build higher level stuff
> easily.

I expect the core will end up with a shallow but large set of interface
tags, because tiny pieces of the implementation get reused in funky ways in
the current folklore interfaces.  Like "for x in thing" requires a
thing.__getitem__ that accepts an integer argument and either returns a
value or raises IndexError, but uses no other properties of "a sequence"
(not even __len__!).  That little piece should be given a name, and the
Sequence interface should specifically say that it implements it.

Similarly. whether a thing supports "len(thing)" is a teensy piece of
behavior that's not unique to Sequence (e.g. Map supports it too, and any
number of user-defined classes that aren't intended to be Sequence or Map).

Maybe we should name these mini-interfaces HasAttr__getitem__ and
HasAttr__len__ <wink>.

healing-the-type/class-split-would-make-it-simpler-ly y'rs  - tim