PEP 245: Python interfaces

[Clark C. Evans]

> http://python.sourceforge.net/peps/pep-0245.html

This is very good work  Michel.  Here are my comments
which I've been mulling over for the last few days.

  a)  First, I'm not sure a new type is needed, perhaps
      classes work just fine (see the PyXML library
      for current interface declaration practices...)
     
      In general, your PEP didn't convince me why
      the class construct couldn't be extended 
      in a reasonable way to satisify the goals
      you enumerated without introducing a new type.

  Assuming that the "class" type can be augmented:

  b)  If the class syntax was extended, perhaps it
      may be useful to add a new statement like
      pass, but could be used to mark "pure" 
      methods (like = 0 in C++), perhaps:

         class X:
            def func(self,z): pure
            
      Then, if any method in a class was marked
      "pure", the class could not be instantiated.
      
  c)  If the class syntax was extended, perhaps
      there might be a way to signify "inherit"
      from "implements", perhaps:

         class X (Y,#Z):
           
      The above class X "inherits" from the
      class Y, and "implements" the public 
      attributes found in class Z, but 
      without sharing the implementation.

   d) What is also missing from Python is
      an "auto-delegation".  An analysis
      of how this fits in or doesn't fit 
      in would be helpful.

   Assuming that a new "interface" type were
   to be added. 

   e) I personally feel that the syntax should
      be much different from the syntax of a 
      class to reduce confusion.  Note that
      maps and lists have different syntaxes.
      The different syntaxes give better 
      context for programmers...

   f) If a new type is added, why not go further?
      Although I don't like the idea of argument
      types in classes... they could very well
      make sence for interfaces.  This could help
      to differentiate the syntax, perhaps:

        interface Y:
           decl func( number as types.IntType, 
                      string as types.StringType,
                      any    as any,
                      cls    as IAnotherInterface ): 
               "This function does such and such"
         
   g)  I like the pre/post condition stuff, however,
       this shoudl be put in a seperate PEP as it
       is seperable and could be added later, no?

   h)  I don't like the string for pre/post conditions.  
       They should have special syntax, perhaps as
       these could be implemented as "local methods?"
   
         interface Y:
             decl func(...) 
                 def pre(self):
                    if ... then raise PreConditionFailure
                 def post(self): pass
                 def test(self): pass

 
   Summary:  I like what you have done, but given your
             requirements, I think we should extend class
             with a "pure" construct instead.

             If we are going to have a new type, then
             a new, more appropriate syntax should be
             created.


Wheu!  I hope this helps! 

Kind Regards,

Clark