[Python-3000] iostack and Oh Oh

[Talin]

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.

-- Talin