[Python-Dev] Re: PEP 246 and Protocols (Was: Sneaky 'super' instances)

[Clark C. Evans]

Oops.  Disregard the last post, it got away too soon.

| On Fri, Jun 13, 2003 at 12:50:53AM -0400, Raymond Hettinger wrote:
| | I don't see any significant downside to 246.  The code is simple
| | enough.  It is useful in at least some cases and provides some
| | support for interoperability.
| ...
| | So, my questions is whether there is any reason not to adopt 246
| | right away?  AFAICT, there is no competing proposal and nothing
| | that would be harmed by adoption.  What's all the fuss about?
| 
| On Fri, Jun 13, 2003 at 08:19:59AM -0400, Phillip J. Eby wrote:
| | Guido has said (and I agree) that if Python includes adapt(), then the
| | Python standard library should use it.
| ...
| | PyProtocols was my attempt to show that a PEP 246 mechanism can
| | actually be pretty agnostic about what kind of interface objects 
| | are used, just like the '+' operator is agnostic about what 
| | object types it's used with.
| ...
| | Ah well.  :)  On the bright side, I think PyProtocols can alleviate
| | *one* of his concerns, which was that having a Python-included interface
| | type would make other interface types (e.g. Zope interfaces) "second-class
| | citizens".  That is, I've demonstrated that it is possible to have a
| | "protocol protocol", thus allowing different protocol or interface
| | types to exist, even if they have no implementation in common (e.g. 
| | Twisted, Zope, and PyProtocols).

Could this approach work:
  
   - use regular class inheritance for static requirements
   - use adapt() for dynamic or custom needs (as shown below)
   - let specific use cases further refine the requirements

This whole 'Interface' issue has been in the works for over
three years now, and potentially great interoperability 
between frameworks and components is being lost.   For example,
why not just have a 'interfaces.py' in the standard library.
The interface for iterators could be something like...
 
  # inside interfaces.py
  class Iterable(object):
      def next():
          """ returns the next value in the iteration, or
              raises StopIteration to finish up
           """
      def __adapt__(cls, obj):
          try:
              return obj.__iter__()
          except AttributeError:
              pass
          // perhaps return a wrapper object
          // for other types, like lists...

     __adapt__ = classmethod(__adapt__)


Then, iter() could be defined something like... 

  def iter(obj):
      return adapt(Iterable, obj)


Best,

Clark