PEP 245

[Alex Shindich]

>Exactly.  In particular, '__' name mangling does not apply to inheritance.
OK, we are agreeing on something... "sigh of relief"


>Yes: C++ sort-of-confuses "I implement an interface" and "I conveniently
>use [some part of] a class in my own implementation" under the single
>rubric of 'inheritance' -- pretty bad in itself, and the distinction
>between public and private inheritance is a helpful band-aid given this
>confusion.  Better, of course, not to have the confusion at all.  In
>Python, we also lack the band-aid, so it's _particularly_ important to
>avoid confusing these two concepts -- both important, but quite distinct.
I personally rarely use inheritance in Python for anything else but to
describe interface-like behavior. For code reuse I prefer containment... But
that is just me...

>COM does not mandate that a C++ compiler is used, nor does it have
>anything to say regarding HOW such a compiler (or one for another
>language, such as Eiffel) be used to implement COM objects -- as
>long as certain binary layouts are obtained, and various semantics
>rules are respected, COM couldn't care less about HOW this is
>brought about, nor WHEN (COM has *NO* concept of "compile time").

OK!!!!!!!!!!!!!!!!! COM was a stupid example!!!!!!!!!!! Yes it only cares
about the memory layout of the virtual tables. And YES, COM components can
be written using anything that is capable of creating C++-compatible virtual
tables. It is just that I happened to write COM code using C++ on a very
frequent basis (and no, I do not use Wizards...), and for the most part I
implement multiple interfaces using multiple inheritance. Not that it is the
only way of doing it.

And why don't we stop the whole COM nonsense here! I love COM, I write COM
code all the time. And YES, I used it as a bad example. Let it rest already.
If you know so much about COM and you feel like arguing, we can find another
forum for that. It still has nothing to do with the original point, what is
the value of adding interface support to Python.

>There are more things in heaven and earth, Mr Shindich,
>Than are dreamt of in your philosophy.
I sense a lot of anger in you...

>_I_ (and the designers of COM)
:)))
>see identity constraints as highly
>pragmatical issues that ensure certain proxying and marshaling
>strategies (and, more generally, certain client-side choices for
>access and usage) will work -- constraints on object implementers
>for the benefit of optimizations in the COM infrastructure (and,
>to a lesser degree of importance, for the benefit of client-side
>coders;
Huh? "lesser degree of importance, for the benefit of client-side coders"?
That is a very one-sided approach to the problem. Interface identity is
being used for marshaling, but there is more to it. I see identity
constraints as being useful because they enable the client coders to rely on
the particular semantics associated with the particular version of the
interface.
>e.g., the "reflexivity" of QI ensures client-code can
>choose to hold a single pointer to a certain interface on a given
>object, and will always be able to QI back to other interfaces at
>need, rather than needing to use some specific 'privileged itf'
>for such purposes).  Different sets of constraints might also work,
>enabling different strategies from client-side, implementer-side,
>and infrastructure, with different performance tradeoffs, but it
>is important to have SOME set of very precise ground-rules for
>"object identity", so that client-code, implementation-code, and
>infrastructure-code, each written in very diverse languages, can
>all work together in harmony (I happen to believe that the very
>set chosen by the COM designers is the ideal one for the use
>cases _they_ were considering -- local, in-process, and fast-
>response-LAN client/server usage -- but, change the use cases,
>and the tradeoffs shift... and so does the optimal definition
>of object-identity rules, cfr. for example the .NET choices).
I am sorry, at what point in time did I ask for a COM interface rules
lecture? WHAT DOES IT HAVE TO DO WITH THE DISCUSSION ON HANDS?
> To me an interface means
> a contract by wich both a component and the client code live. All I am

>add any kind of co-variance, which both
Point well taken. That is true.

>A _pragmatical_ person, on the other hand, takes into due
>account these limitations _and still documents these kinds
>of constraints_ as formally as feasible given whatever
>technology is at hand.
I use the technological marvel called text editor to document my code.

>> Oh, Lord! Leave the COM alone. Why don't you talk about similarities with
>> Java?
>Because YOU mentioned COM -- a very interesting and hugely successful
>design for a cross-language object-model, which succeeds in good part
>by doing the very OPPOSITE of what you SAID it was doing [the idea of
>taking COM as an EXAMPLE of "compile-time" was particularly hilarious
>to a COM expert, and I wanted to share the mirth:-)... and possibly
>help dispell some misconceptions].

>is used instead of an array, and *THAT* is *OBVIOUSLY* not compile-time
>type-safe since ANY object can be stuffed into it -- it doesn't take
>much Java knowledge to point this out:-).
Wait till Java generics become available...

>And whoever thinks that a good design is less valuable when a
dynamically-typed language, rather than a
>statically-typed one, is to be used for the coding, needs far more
>reprogramming than I can supply:-).
When did I say about good design being only needed for statically types
languages? I think you are hallucinating...
What I SAID, is that Python has it's own SET OF INTROSPECTION-BASED PATTERNS
that generally allow you to accomplish same things as patterns that are more
INTERFACE BASED!

>If you include C-coded extensions among the "existing language
>constructs" of Python, then, yes, I cannot think of ANYTHING
>that cannot be _implemented_ using them.  There may be no clear
>way of _expressing_ what is going on in Python, when enough of
>the crucial stuff is hidden in a C-coded extension (have you
>*studied* the current [and excellent] implementation of the COM
>support, on both the C-coded and Python-coded sides...?!-).

Not that it is something that I have achieved, but I believe I looked at the
first underpins of the Python-COM framework before Mark Hammond had a chance
to see it...
But then again I was lucky to work with someone who first wrote the COM
support for Python.

IN ALL HONESTY, I WOULD LIKE TO DISCONTINUE THE COM DISCUSSION!!! If you
have something you would like to argue with me about, please mail me
directly. YOU MADE YOUR POINT EXPLAINING THAT COM IS NOT LANGUAGE-SPECIFIC,
AND THAT COMPILE TIME CHECKING IS PROVIDED BY THE USE OF C++ AND NOT COM
TECHNOLOGY ITSELF. BUT PLEASE, STOP COM LECTURES!!!! THIS IS A PYTHON
NEWSGROUP!!!!