What if python modules were COM components?
Dan Connolly
I was hoping to find a few hours to code this up, but
before I forget this idea, or it becomes too late:
I was reading Guido's 1.4 notes from the python workshop[1],
and studying COM[2], and I had an idea:
re-structure the python runtime along the COM guidelines.
First a note: Guido wrote:
------
The virtual machine will be rewritten to eliminate the C stack (in
most cases, anyway). This will makes it possible to implement
migratory Python prorams, as well as portable coroutines. Together
with an asynchronous I/O library, this could be used to implement
portable threads. I hope that this reimplementation will pave the way
to a faster implementation as well.
------
This is the most important change to python I can imagine. See my
earlier article on "cooperative multi-tasking"[3].
Now on to my crazy COM idea:
It's related to what Guido wrote:
-------------
Many arbitrary restrictions on argument types to built-in functions
and operations will be lifted, using the abstract object interface. In
particular, many more functions/operations will support an arbitrary
mapping or sequence instead of just a dictionary, tuple or list.
-------------
The idea is that python objects would be COM objects, and python
modules would be COM components.
Among others, here are some specific changes:
in object.h, rather than laying objects out as:
{
int ob_refcnt;
struct _typeobject *ob_type;
}
they'd be laid out as:
{
struct _IUnkown *vtble;
}
where:
typedef struct _IUnknown{
int QueryInterface(uuid *id, IUnknown *outer, void **out);
int Addref(IUnknown *obj);
int Release(IUnknown *obj);
} IUnknown;
and the PyTypeObject structure would go away. In stead of:
sequence_methods *sq = u->ob_type->tp_as_sequence;
if(sq) { ... }
we'd write:
sequence_intf *sq;
if(u->vtble.QueryInterface(&Sequence_IID, NULL &sq) == OK){
...
}
This would mean that Py_IncRef/DecRef require a vtable lookup
and a function call, rather than just a read-modify-write.
I'm not sure what the performance impact of this would be.
It might be useful to share technology with COM in the area of
module initialization; i.e. rather than init_xxx(...), we
could use CoRegister*(...).
And there's a parallelism between the way python looks up modules
by name and the way OLE automation finds programs by "progID".
Microsoft is porting ActiveX to unix (well... having it ported). As
part of that, they're implementing the registry and the running object
table in unix. The idea of having the running object table in shared
memory looks really cool, though I wonder about how to implement
multi-user security in that world. (They did it for NT... I wonder
how?)
It seems that there is synergy between COM's IDispatch and python's
object model -- getattr in particular. I haven't figured out the
details yet.
Has anybody looked at the way microsoft integrated Java and COM?[4]
This is basically the same idea.
My intuition says that this could result in a large increase
in code reusability: at least on the wintel platform, all those
COM components would instantly be python modules. I'm not sure
how useful this would be in practice. It would depend on how
neatly the interfaces exported by those components mesh with
python idioms. For example, smooth integration of IDispatch
into the python runtime would be a HUGE win: all OLE automatable
controls would Just Work like they do in VB. I know this is
already possible in WinPython, but it's not as smooth as it
could be.
COM components don't tend to be usable on other platforms; i.e.
source code isn't usually available.
But: what if, for the same effort of making a python module
out of your C code, you got a COM control out of it? It
might change the balance between:
(a) follow the python FFI guidelines, and get
a python module and COM component in
one shot, or
(b) follow the perl FFI guidelines, and get a
perl module
(c) follow the Tcl FFI guidelines, and get
a Tcl extension
The python and COM programming models are already very much aligned:
reference counting, properties/attributes, etc. The only change
left is to adopt QueryInterface, which seems like a good idea
to me.
The COM strategy regarding threads seems to apply as well: you don't
get them unless you ask for them. And if you ask for them, but other
modules in your address space did not, an "apartment" thread is set
up, and calls are serialized across the boundary (enter ILU...).
As I said in [3], this sort of thing allows a consistent high-level
threaded programming module ala the M3 interfaces, without necessarily
losing compatibility with non-threadsafe guts.
[1] http://www.python.org/workshops/1996-06/future.html
[2] http://www.microsoft.com/oledev/olecom/title.htm
[3] http://xp9.dejanews.com/getdoc.xp?recnum=10610736&server=dnserver.db96q1&CONTEXT=845526260.11362&hitnum=5
Subject: Toward Cooperative Multitasking [was [ANNOUNCE] async sockets support library]
From: conn...@w3.org (Dan Connolly)
Date: 1996/03/25
Message-Id: <yprn3f6w2...@beach.w3.org>
References: <x6lokv9...@squirl.nightmare.com>
Organization: W3C
Newsgroups: comp.lang.python
[4] http://www.microsoft.com/intdev/sdk/docs/javavm/java_000.htm
--
Daniel W. Connolly We believe in the interconnectedness of all things"
W3C Architecture Area Lead PGP: EDF8 A8E4 F3BB 0F3C FD1B 7BE0 716C FF21
<conn...@w3.org> http://www.w3.org/People/Connolly/
Mark Hammond
Whew :-)
Your ideas are certainly radical :-)
I'll take this opportunity to tell you where the "COM Working Group"
is at with the new COM support. Your ideas go a fair bit further.
COM server support has been broken totally from Pythonwin/MFC. There
is now a DLL which COM uses, and this DLL loads Python itself, and
also loads the correct Python code.
If you have an existing Python class, and you wish to expose it via
COM, then you need to make a 1 line addition to your class - a list
of the "public methods". Then all you need do is register your
class, and away you go.
The VTBL thing is interesting. To cut a long store short, full VTBL
support exists - you Python object will be able to be called from a C
COM client. The server framework is extendable - you can support
interfaces other than IDispatch - eg, we have a test harness that
exposed a VTBL implementation of IAvtiveScript, IObjectSafety, etc.
There is also full client support. Although you can not say "import
Excel.Application", you can say:
excel = win32com.client.Dynamic.Dispatch("Excel.Application")
excel.Visible = 1
excel.Cells(0,0).Value = "Hello"
And all works.
The latest Pythonwin beta (unannounced, but does exist :-) has the
latest of all this stuff. It is starting to look pretty slick.
There is one thing that is a problem: Consider:
a = excel.Visible
b = excel.Visible()
Unfortunately, at __getattr__ time, I have no idea if the "Visible"
attribute is being asked for as a property reference, or a function
call.....
Mark.
----------------------------------------------------------------------
Mark Hammond - MHam...@skippinet.com.au
Check out Python - _the_ language for the Web/CGI/Windows/MFC/Unix/etc
<http://www.python.org> & <http://www.python.org/ftp/python/pythonwin>
Tibi Berkovits
Mark Hammond <MHam...@skippinet.com.au> wrote in article
<1996101800...@minotaur.labyrinth.net.au>...
>
> And all works.
>
> The latest Pythonwin beta (unannounced, but does exist :-) has the
> latest of all this stuff. It is starting to look pretty slick.
>
>
Is this latest Pythonwin beta available somewhere for download ?. This
stuff
sounds very intersting; any pointers will be appreciated.
-------------------------------------------------------
Tibi Berkovits - <ti...@probe.att.com>
AT&T