[Python-3000] Abilities / Interfaces

Phillip J. Eby pje at telecommunity.com
Wed Nov 22 21:54:20 CET 2006


At 12:28 PM 11/22/2006 -0800, Guido van Rossum wrote:
>So maybe there are even less differences between the different POVs.

Yep.


>I'm not arguing that generics aren't strictly more powerful than
>interfaces -- I just think that interfaces don't necessarily deserve
>the bad rep you're creating for them, and I'd like to have interfaces
>prominently in Py3k's toolbox (as well as generics) rather than having
>to hide them in the closet.

My point is that I'm not trying to create a "bad rep", I'm just emphasizing 
that it's easier/more useful to define interfaces as collections of generic 
operations, because it makes the simple cases simple and powerful, and the 
complex ones possible.  Doing it the other way around makes all of the 
cases more complex, and loses other capabilities.

My use of the word "unnecessary" isn't a moral judgment of interfaces, it's 
an argument about how best to layer the various concepts we want to 
have.  Interfaces aren't necessary for simple things, and it's better (IMO) 
if we define them *in terms of* simpler things, because then people don't 
have to learn about them unless they need something more complex.

And if they need something more complex, it is also more likely (I believe) 
that they will have more specialized needs.  So, I intended to suggest that 
if we just do the basics (operations) and allow others to define interface 
frameworks atop that, then we can avoid overgeneralizing from insufficient 
experience.  However, in the expanded discussion it seems to me that you 
have goals for additional abilities you'd like to see sooner rather than later.

What worries me about Java-style interfaces is that you can't split and 
recombine them in arbitrary ways, without effectively decomposing them into 
single-operation interfaces using multiple inheritance.  At which point, 
you just might as well have treated them as operations to start 
with!  Thus, taking an operation-based approach means there need not be a 
concept of the "one true sequence interface", just the *default* sequence 
interface.  If my needs are more or less expansive than the default 
"sequence" interface, I should be able to do something like (sequence.len, 
sequence.iter) and recombine a new interface.

This would also make the interface committee's job at least somewhat 
easier.  :)



More information about the Python-3000 mailing list