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

Phillip J. Eby pje@telecommunity.com
Fri, 13 Jun 2003 17:35:19 -0400


At 09:44 PM 6/13/03 +0000, Clark C. Evans wrote:

>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...

This is moot.  Guido has made it clear that until he's had time to think 
over all the issues, *no* interface implementation is getting in the 
standard library.

Meanwhile, PyProtocols is available under the PSF, so any framework that 
wants to bundle it in their distribution is free to do so.  If it becomes 
popular, I suppose there will need to be a versioning mechanism so a 
framework doesn't overwrite a newer version with an older one.  That's the 
only issue that would even be marginally resolved by inclusion in the 
standard library, apart from the implied "blessing".

However, I don't know that the "blessing" is even required at this 
point.  If PyProtocols (perhaps with the enhancements suggested by Samuele 
and others here) doesn't catch on, I'm not sure what else *could* make PEP 
246 popular.  Or to put it another way, if it doesn't catch on by its own 
merits, why decorate the standard library with interfaces to support it?

This is why one of my requirements for PyProtocols was that it absolutely 
had to support declaring adapters for built-in types, and why another one 
was that it should be possible for two people to independently declare 
equivalent or overlapping protocols, and then have a third party glue them 
together.  PEP 246 without an "open protocols" protocol, doesn't support 
this latter requirement.  That, I believe, is the heart of the "chicken and 
egg" problem for PEP 246 as a standalone protocol.  It's sort of like 
having 'iter()' but not having 'next()', or maybe the other way around.  :)