PEP 245

Michael Chermside mcherm at destiny.com
Tue Apr 3 23:44:33 EDT 2001


Alex... I just wanted to say that your statements (quoted below) were
extremely clearly-worded and easy to understand. Nice job of explaining
it... perhaps some of this wording should even go in the PEP. To me,
this (and other parts of the post... I didn't want to waste bandwidth
by quote excessively) clearly explains the intent of interfaces as well
as what they are NOT intended to achieve.

-- Michael Chermside


On Sun, 1 Apr 2001, Alex Shindich wrote:

> 
> Take me for example.  If I were a python object, I'd be an instance of a
> class that is generalized by two other classes, my mom and dad.  That's my
> type, my genetics.  Now, let's say you were a function that expected a
> 'Python programmer'.  You could wire that expectation to my implementation
> (my class), but then, I'd be the only "kind" of python programmer you could
> use.  You could wire it to my generalized classes, but then you could only
> use me and my two sisters, and they're not python programmers.
> 
> What you want is anyone, anybody, regardless of their genetic
> implementation, to work in your function because they assert "I am a python
> programmer."  It's a contract, protocol, interface, call it what you will:
> 
> class Michel(Reg, Loretta) implements PythonProgrammer:
>     pass
> 
> In terms of verification and enforcement, you can go through the expensive
> task of verifying my previous employment, my academic history, my
> contributions to python, etc, just once (verfication) or *every* time
> you worked with me (enforcement) or you could use the much cheaper method
> of trusting me when I say I am a Python programmer.  PEP 245 does not
> specify the policy you can use, all are possible.
> 
> The idea of PEP 245 is to separate object introspection from
> implementation.  For example, you can create an object that quacks and
> swims like a dictionary, but will not work for you as the right hand
> component of an "exec 'x=5' in dict" statment.  This is because the exec
> code checks the object based on its type, on its genetic makeup, not on the
> functionality it asserts itself to have.




More information about the Python-list mailing list