[Python-3000] Abilities / Interfaces

[Phillip J. Eby]

At 11:16 AM 11/22/2006 -0200, Gustavo Niemeyer wrote:
>I've lost you here.  As I understand interfaces, their most important
>feature is indeed being a "comment in the form of code", and I hope
>they continue to be that way.

What does it add to have to declare a class as being "Iterable", if it 
already implements __iter__?  What does the notion of "Iterable" add to the 
execution *or* understanding of the code?

If you say that it is because having "Iterable" is needed to distinguish 
different possible interpretations of the same method name(s), then why not 
just have method namespaces to begin with?

"defop" is one way to do that, of course, but there could easily be others, 
like a "namespace" statement inside of classes that would contain the 
method definitions.

I'd like to try to meet the needs, without assuming that "interfaces" are 
the right answer.  Indeed, if interfaces are considered the answer, I want 
to know what the question is.  :)  Many years ago, I helped to create 
Zope's interface adaptation system, and I built PyProtocols as well, using 
interfaces quite extensively in PEAK.  So, I am familiar with the presumed 
benefits of interfaces as well as their drawbacks -- especially their 
drawbacks.  And chief amongst those drawbacks are complexity and 
duplication.

In essence, interfaces turn libraries into "frameworks", but generic 
functions turn frameworks into libraries.  I didn't really discover this 
until January of last year, though, when I did some experiments in 
replacing various PEAK interfaces with generic functions:

http://dirtsimple.org/2005/01/like-acid-for-frameworks.html

The experience of refactoring was what made me realize that generic 
functions weren't just for obscure fancy use cases like security rules and 
binary math operators.  They *gutted* my interface-based code down to 
nothing -- hence my description of them as being "like acid for frameworks".