[Python-3000] Abilities / Interfaces

[Phillip J. Eby]

At 04:14 PM 11/22/2006 -0800, Guido van Rossum wrote:
>But that's a limitation of Java interfaces (and perhaps of Zope
>interfaces); it doesn't have to be a limitation of Python 3000
>abilities.

Agreed -- but some people made statements that implied this was their 
prototypical vision of "interface", and I was concerned that you considered 
it the canonical model as well, since you referenced both Java and Zope.


> > 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.
>
>I'm not sure I understand the significance of prefixing len and iter
>with "sequence." in your example. After all len and iter are globals.

There was no significance, it was because I had the Zope/Java interface 
model in my head at the time and I spoke through that paradigm.  IOW, just 
a brain fart.  :)


>And a default interface will surely tend to become a de-facto
>standard.

Sure...  except that as long as the operations define compliance, then the 
"interface" is just an explanation of which operations are required.  You 
can always require a lesser interface (such as iter) rather than a more 
complex one.


>What's your view on the interfaces for numbers and strings? I really
>don't think it's very useful to care much about objects that implement
>+ and * but not / or ** -- while mathematicians have tons of use cases
>for those, programmers rarely do. As long as those mathematicians can
>create their own interfaces and apply them to the standard types they
>should be happy; the rest of us will be served well by a simple
>hierarchy e.g. Number, Complex, Real, Integer. Even more so for
>strings; I expect that a single String interface would cover most
>uses. Well, perhaps there ought to be something more basic
>representing the shared operations of strings and bytes. But that's
>about it.

Yep, pretty much.  However, note that all of these "interfaces" are 
actually more like *data types*.  For immutable data types, I would argue 
that what you care about is the ability to treat an item "as a" string or 
whatever.  That is, "can I cast this thing to a string without data loss or 
noise?"  "Can I cast to some concrete integral type without loss of 
precision?"  Note too that these casts are *operations* -- perfect for 
representation as generic operations like int.cast and str.cast.  Number, 
Complex and Real are a little harder to place, since there are no concrete 
types for those, but there's no reason not to just have the three casting 
generic functions, and boom, you're done.

Now, when you move back up to "protocols" like sequence or arithmetic, 
we're again talking about single operations (or sets thereof), because 
rarely does any one piece of code require *all* sequence or arithmetic 
operations.  Ergo, little reason to have a single fixed "interface" 
spelling out every aspect of the protocol, versus using generics like 
operator.getitem et al to denote the required capabilities.

(Note that in a 'defop' world, it may make sense to put 'operator' in the 
builtin namespace rather than requiring it to be imported.  Or maybe it 
doesn't.  I haven't thought about that one deeply yet.)


>Container and file types are a different story; there are many partial
>reimplementations of the basic patterns and it is useful to be able to
>describe fairly minimal custom interfaces composed of a small number
>of operations.

Yep.


>The code will continue to evolve and be refactored. But I don't think at
>any point I'll need to break my interfaces up into individual
>operations.

True enough, however if the concept of "interface" is implemented in terms 
of "set of operations", this allows for such things as automatically 
generated adapters, and partial implementations ala some of Ping and Alex's 
past proposals, where UserList and UserDict would actually be "interfaces" 
rather than concrete objects.