[Python-3000] Abilities / Interfaces
Phillip J. Eby
pje at telecommunity.com
Thu Nov 23 01:37:58 CET 2006
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
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
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
>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
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
>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
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.
More information about the Python-3000