PEP 245

Alex Shindich shindich at itginc.com
Mon Apr 2 19:53:34 EDT 2001


>in C++, one normally uses _private_ inheritance for this specific purpose
There is nothing private in Python. There is "__" name mangling of course,
but that is it.
But your point is well taken. Code reuse should not be mixed with class's
interfaces. Still, in C++ multiple inheritance is used as the simplest for
of interface implementation, and abstract classes with only virtual methods
can be treated as interfaces.

>COM, per se, has no concept of 'compile time' either.  Among the languages
>best supporting COM are some (such as Python:-) which do very little, if
>anything, "at compile time".
OK. That is partially true. If a COM component is implemented using multiple
inheretence, then C++ compiler will force you to implement all the interface
methods. If agregation, composition, or flyweights are used, then there is
no compile time safety.

>In Python's case, we don't share the needs and design constraints which
>led to COM's rules (proxying, marshaling...), so there is no need to
>impose identity-constraints and the resulting complications (even today,
>Python allows an object to keep identity BUT change behavior, e.g. by
>changing its __class__).  But that has really nothing to do with
>compile-time vs run-time.
I see identity constraints as philosophical issue. To me an interface means
a contract by wich both a component and the client code live. All I am
saying is that the proposed definition is to vague, and I don't particularly
care for it. To me the definition of an interface that only guarantees the
fact that a class will have attributes with particular names of type "bound
function" is handicapped and useles!

>I see nothing in the interface-adaptation PEP that can be said to
>be borrowed from other languages (even if one counted COM as "a
>language", which of course it isn't -- it's an object-model
To be precise "Component Object Model".
>, which
>can be, and is, implemented by a huge variety of languages), and
>most particularly nothing that somehow depends on 'staticity' vs
>Python's 'dynamism'.
Oh, Lord! Leave the COM alone. Why don't you talk about similarities with
Java? And in my mind, the notion of the interface is far more valuable for
staticaly types languages, component models, what have you. And could please
somebody explain to me what advantages the proposed PEP give us over simple
documentation.

BTW. Alex, you mentioned that Python supports COM well... As you can see
interface support could be implemented using existing language constructs.

Regards,

AlexS





More information about the Python-list mailing list