[Python-Dev] PEP 246: lossless and stateless

[Michel Pelletier]

> Date: Fri, 14 Jan 2005 02:38:05 -0500
> From: "Phillip J. Eby" <pje at telecommunity.com>
> Subject: Re: [Python-Dev] PEP 246: lossless and stateless
> To: guido at python.org
> Cc: "Clark C. Evans" <cce at clarkevans.com>, python-dev at python.org
> Message-ID: <5.1.1.6.0.20050114014238.0308e850 at mail.telecommunity.com>
> Content-Type: text/plain; charset="us-ascii"; format=flowed
> 
> Each of these examples registers the function as an implementation of the 
> "file.read" operation for the appropriate type.  When you want to build an 
> adapter from SomeKindOfStream or from a string iterator to the "file" type, 
> you just access the 'file' type's descriptors, and look up the 
> implementation registered for that descriptor for the source type 
> (SomeKindOfStream or string-iter).  If there is no implementation 
> registered for a particular descriptor of 'file', you leave the 
> corresponding attribute off of the adapter class, resulting in a class 
> representing the subset of 'file' that can be obtained for the source class.
> 
> The result is that you generate a simple adapter class whose only state is 
> a read-only slot pointing to the adapted object, and descriptors that bind 
> the registered implementations to that object.  That is, the descriptor 
> returns a bound instancemethod with an im_self of the original object, not 
> the adapter.  (Thus the implementation never even gets a reference to the 
> adapter, unless 'self' in the method is declared of the same type as the 
> adapter, which would be the case for an abstract method like 'readline()' 
> being implemented in terms of 'read'.)
> 
> Anyway, it's therefore trivially "guaranteed" to be stateless (in the same 
> way that an 'int' is "guaranteed" to be immutable), and the implementation 
> is also "guaranteed" to be able to always get back the "original" object.
> 
> Defining adaptation in terms of adapting operations also solves another 
> common problem with interface mechanisms for Python: the dreaded "mapping 
> interface" and "file-like object" problem.  Really, being able to 
> *incompletely* implement an interface is often quite useful in practice, so 
> this "monkey see, monkey do" typing ditches the whole concept of a complete 
> interface in favor of "explicit duck typing".  You're just declaring "how 
> can X act 'like' a duck" -- emulating behaviors of another type rather than 
> converting structure.

I get it!  Your last description didn't quite sink in but this one does and 
I've been thinking about this quite a bit, and I like it.  I'm starting to 
see how it nicely sidesteps the problems discussed in the thread so far. 

Partial implementation of interfaces (read, implementing only the operations 
you care about on a method by method basis instead of an entire interface) 
really is very useful and feels quite pythonic to me. After all, in most 
cases of substitutability in Pyhton (in my experience), it's not the *type* 
you do anything with, but that type's operations.  Does anyone know of any 
other languages that take this "operational" aproach to solving the 
substitutability problem?

There seem to be some downsides vs. interfaces (I think) the lack of "it's 
documentation too" aspect, I find zope 3 interfaces.py modules the best way 
to learn about it, but again the upside is, no complex interface 
relationships just to define the subtle variations of "mapping" and users can 
always just say help(file.read). 

Another thing I see used fairly commonly are marker interfaces.  While I'm not 
sure of their overall usefullness I don't see how they can be done using your 
operational scheme.  Maybe that means they were a bad idea in the first 
place.

I also think this is easier for beginners to understand, instead of "you have 
to implement this interface, look at it over here, that's the "file" 
interface, now you implement that in your object and you better do it all 
right" you just tell them "call your method 'read' and say its 'like 
file.read' and your thing will work where any file can be read.

-Michel