PEP 245

[Clark C. Evans]

On Thu, 5 Apr 2001, Alex Martelli wrote:
> Bingo!  A "contract" -- including some promises
> on the existence and signature of methods, some
> on functionality (pre/post conditions), even,
> maybe, some on performance.  Austern's "Generic
> Programming and the STL" focuses on "a set of
> abstract _concepts_ ... a type conforms to one
> of those concepts if it satisfies a certain set
> of requirements ... this hierarchy of concepts is
> the conceptual structure ... the most important
> part ... what makes reuse and interoperability
> possible ... the essence of generic programming".

I _really_ like the word "contract".   Interface
brings into my mind all kinds of hoops that I 
have to jump in order to connect two components.
What I like about Python thus far is that it 
assumes the programmer is right... and marches
along, not being too smart, until it can't go 
further.  This is a very nice property of the
language and I can see people balking if 
"java-style interfaces" are added.

Michel,  

   It may be too late, but how about
   ammending 245 to use the word "contract"
   instead of "interface".  Just thinking.
   Words bring with them meaning, and your
   proposal isn't anywhere near as strict
   as Java or COM interfaces...   But, perhaps 
   I'm being stupid here.
   
And I whole-heartedly agree with Alex below.

> Focusing on the amount of compile-time, or even
> run-time, _checking_, that a certain language can
> offer, is missing the point -- _expressiveness_
> is what we need to ask, so the "abstract concepts"
> can be *stated* formally.

...

> No problem!  Letting the programmer express his
> or her _design intent_ clearly in the language
> will be a big help anyway.  The very least we can
> ask is being able to _state_ "this thingy, here,
> conforms to the 'ReadableForwardOnlyStream' abstract
> concept" (call it protocol, interface, concept --
> the choice of name is a secondary issue); even
> better, by PEP 246, being able to ask for some
> 'adaptation' of object-to-concept if feasible.
> 
> Whatever subset of the concept can be expressed
> in the language will further help, and a further
> small help may come if some checking can also be
> automatically performed (the earlier the better),
> but *all of this is secondary* -- the *primary*
> need is for direct support of the primitive
> notion of 'protocol' (aka 'interface', etc, etc),
> as (e.g.) per PEP 245, and the most useful single
> step beyond that is the notion of adaptation (as
> per PEP 246).