[Python-3000] Abilities / Interfaces

[Guido van Rossum]

On 11/22/06, Phillip J. Eby <pje at telecommunity.com> wrote:
> 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.

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.

> 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.
And a default interface will surely tend to become a de-facto
standard.

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.

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.

User-defined types are different again. I've recently had the
opportunity to think a bit about refactoring a library that works with
Perforce changelists (CLs; Perforce is a commercial source control
system) to be generalized into supporting Subversion revisions. There
are a lot of operations one can do on a Perforce CL objects. There is
a lot of code that receives, produces or passes around Perforce CL
objects. Some of this generalizes to Subversion; some of it doesn't.
But I don't expect I'll be needing more than three interfaces to
describe the eventual refactoring: an abstract source control revision
class as the base interface, and two subclasses specializing for
Subversion and Perforce. Sure, eventually someone will want to support
CVS, or RCS, or (more likely) git or Mercurial or what have you. 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.

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

Anything to make their job easier. I guess we'll have to lock them
(us? :-) up in a room for several days before/after PyCon.

-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)