[Types-sig] Interfaces: Scarecrow implementation v 0.1 isavailable

Jim Fulton jim@digicool.com
Mon, 06 Dec 1999 17:28:10 -0500

John, Skaller, skaller@maxtal.com.au wrote:
> [Scarecrow v 0.1]

Wow, talk about a slow response (from me). :)
I'm trying to wrap this phase of the "interface" project
up and need to response to this, er, one comment on the .1
version of the interface implementation.

Note that the .1 release is not currently available but 
the .2 release soon will be.

> I'll try to add this to interscript, and integrate it with my protocols
> module. :-)

Cool. Any progress?

> Sigh. It's a special case of a protocol.
> >  Special-case handling of classes
> >
> >    Special handling is required for Python classes to make assertions
> >    about the interfaces a class implements, as opposed to the
> >    interfaces that the instances of the class implement.  You cannot
> >    simply define an '__implements__' attribute for the class because
> >    class "attributes" apply to instances.
>         Yes you can. And you must. See below.
> >    By default, classes are assumed to implement the Interface.Standard.Class
> >    interface.  A class may override the default by providing a
> >    '__class_implements__' attribute which will be treated as if it were
> >    the '__implements__' attribute of the class.
>         This cannot work.

Uh, but it does.

> What you need to do is fix the lookup routines,
> that is, the routines that test if an object provides an interface, etc,
> so that they look in the dictionary of an object directly!
>         Don't use 'getattr', use
>         object.__dict__.has_key('__implements__')
> and
>         object.__class__.__dict__.has_key('__class_implements__')

I don't see how this can work for the following two reasons:

  1. if you evaluate::


     you'll get the answer for the class' instances, not the class.
     Then again, maybe I'm missunderstanding you.  Perhaps you could
     give a complete alternative implementation for 'implementedBy'.

  2. A compromise made by the scarecrow proposal is to allow
     "implements" assertions to be interited. For this, getattr is
>         This works, it is what I do in my protocols module,
> and it gets rid of the special case, which is a sure sign of a design fault.
> >  Trial baloon: abstract implementations
> >
> >    Tim Peter's has expressed the desire to provide abstract
> >    implementations in an interface definitions, where, presumably, an
> >    abstract implementation uses only features defined by the
> >    interface.  For example:
> >
> >      class ListInterface(Interface.Standard.MutableSequence):
> >
> >        def append(self, v):
> >           "add a value to the end of the object"
> >
> >       def push(self, v):
> >           "add a value to the end of the object"
> >           self.append(v)
>         Yes. This is useful. It is the basis for mixins in C++.
> But one has to ask the question: why not just use a class,
> and add a 'defer' keyword to Python.

Because you will still be creating a separate interface.  You'll use the 
'defered' method on the interface to compute an base class with the
implementation. I'll try to clarify this in the documentation.
>         Then again, you could just say 'pass'.
> >Issues
> >
> >  o What should the objects that define attributes look like?
> >    They shouldn't *be* the attributes, but should describe the
> >    the attributes.
>         Obviously, they should themselves be interfaces.
> Since attributes are just objects. :-)

I think that an attributes description could include it's interface, 
but it might include other information as well, such as it's documentation.


Jim Fulton           mailto:jim@digicool.com   Python Powered!        
Technical Director   (888) 344-4332            http://www.python.org  
Digital Creations    http://www.digicool.com   http://www.zope.org    

Under US Code Title 47, Sec.227(b)(1)(C), Sec.227(a)(2)(B) This email
address may not be added to any commercial mail list with out my
permission.  Violation of my privacy with advertising or SPAM will
result in a suit for a MINIMUM of $500 damages/incident, $1500 for