PEP 245: Python interfaces
Clark C. Evans
cce at clarkevans.com
Fri Mar 23 09:02:54 CET 2001
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:
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:
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?"
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
Wheu! I hope this helps!
More information about the Python-list