PEP 245

[Alex Martelli]

"Clark C. Evans" <cce at clarkevans.com> wrote in message
news:mailman.986439487.17064.python-list at python.org...
    [snip]
> > PEP 246 does not guarantee the symmetric behavior, which I
> > think is required for going back and forth between object's
> > interfaces. Although the PEP says that such behavior may be
> > added. (See PEP's text)
>
> I'm just not a COM guru,

I am (or, if I'm not, please don't let my employers know, as
they remunerates me richly under the misapprehension that I am:-).

> and I don't know the advantages or
> disadvantages that come with this restriction.  Thus, I left

I do, and the semantic restrictions of "COM object identity"
make a *lot* of sense... _in the context of COM's typical
use-cases_, *particularly* the transparent use of objects
(with proxies and marshaling) across different apartments/
processes/hosts.  But these are *NOT* the typical use-cases
for PEP 246!  If such constraints were imposed, we'd be left
with just about only the DIS-advantages, for very little gain.

> it as an open issue for those who really understand this
> deep stuff...  I just want a standard way to adapt objects.

Me, too; and, in that context, identity-constraints had
better not be there.  Otherwise, we end up with AT LEAST
two ways to ask for adaptation-to-protocol -- one that
is equivalent to COM's QueryInterface, WITH constraints,
and one which is equivalent to COM's IServiceProvider
interface, WITHOUT constraints (i.e., the latter is allowed
to return an object with a different identity from that
of the service-provider object -- in other words, one that
lacks the ability to 'navigate' back to the original).

Python's object-identity concept is the one expressed by
the id() built-in function.  There is no real need to
superimpose _another_ sub-definition of "weak identity",
objects with different id()'s which are partitioned into
equivalence classes by the ability to 'navigate' between
them by adaptation.  In COM, you never "hold an object",
only one or more of its interfaces, so the ONLY identity
that is meaningful is the "equivalence" defined by the
semantic identity-constraints.  In Python, you DO "hold
an object" -- that is the one and only job of any variable,
item in a dictionary or list, attribute in an instance...
the situation is really very different!


> With this in mind, I actually like PEP 245 (Interfaces) as it is.
> Adding a QueryInterface mechanism to it would just confuse issues.
> Having an othognal adapt mechanism is better... besides, it could

This also seems to me to be the case.


Alex