[Python-3000] iostack and Oh Oh

Guido van Rossum guido at python.org
Thu Dec 7 20:01:22 CET 2006


That sounds like a reasonable summary to me. One nit below.

On 12/7/06, Talin <talin at acm.org> wrote:
> Phillip J. Eby wrote:
> > At 09:59 AM 12/5/2006 -0600, Guido van Rossum wrote:
> >> My point is that an interface can *document* (at least in English) a
> >> "contract" about the invariants between operations. While I'm not into
> >> enforcing or verifying such contracts, I'm very interested in
> >> documenting them. For example, something that has "mapping" behavior
> >> has a very different relationship between x[y] and "y in x" than
> >> something that has "sequence" behavior.
> >
> > I assumed this didn't need answering.  If you're using the interface solely
> > for documentation, then a namespace-oriented interface suffices to provide it.
>
> I'm guessing that Guido's use of the word 'document' means something
> more than just conveying information to a human reader.
>
>  From what I can tell, the argument boils down to this: You are saying
> that a class is merely the sum of its attributes and methods, and Guido
> is saying that it's not.
>
> For example: You cannot deduce by examining the methods of a list that
> the keys are required to be consecutive integers starting from 0. Lists
> have __getitem__, but so do maps; They support len(), but so do maps;
> and so on.
>
> Thus, lists embody a particular behavior contract (called 'concept' in
> C++ template land). (The word 'interface' and 'ability' has been used in
> this context, but that's somewhat misleading. [1] [2]) The concept is
> supported by the methods of the class, but is only incompletely
> derivable from them.
>
> I think what Guido is looking for is a way to signal that a class obeys
> a given behavioral contract, and a way to inspect the object, both at
> runtime *and* to a human reader, and discover what contracts are
> supported by the class.
>
> On the other side of the argument is the fear that such explicitness
> will lead to Java-style type bureaucracy, and lead to the death of
> implicit, a la 'duck', typing.
>
> The response to that, I think, is that we're not looking to replace duck
> typing but only to supplement it - in other words, this extra
> information would only be used to convey that which is not derivable by
> inspection of types and methods.
>
> [1] The reason that I think 'ability' is misleading is because what
> we're really talking about is a *disability* - a limitation on what
> inputs a class can accept. Also, one tends to think of the abilities of
> a class as its methods, whereas what we're talking about here is a way
> to describe the relationships *between* the methods.
>
> [2] The reason I think 'interface' are misleading is due to its Java
> connotations, in which an interface is a description of a bunch of
> methods as well as a signal of an abstract type, but in this case I
> think what they want is *only* the contract signal and not the method
> declarations.

I don't see it this way. The methods are part of the contract -- the
contract talks about specific methods *and* how they work together. I
still believe this is also what Java interfaces are for, at least in
the best of circumstances, like the collections framework (maybe I
should ask Josh Bloch about this).

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


More information about the Python-3000 mailing list