Mailing List Archive

Python and COM?
Rm9yIGEgQ09NIHNlcnZlciBpbXBsZW1lbnRlZCBpbiBweXRob24sIGNhbiBhIHR5cGUgbGlicmFy
eSBiZSBnZW5lcmF0ZWQ/DQoNCkkgd291bGQgbGlrZSB0byBiZSBhYmxlIHRvIGRpc3RyaWJ1dGUg
c29tZSBvZiB0aGUgd29yayBJJ3ZlIGRvbmUsIGJ1dCBtb3N0IG9mIHRoZSBwZW9wbGUgdGhhdCB3
b3VsZCB1c2UgaXQgd291bGQgYmUgdXNpbmcgVkIvVkJBIHNvIEkgd291bGQgbGlrZSBleHBvc2Ug
dGhlIFB5dGhvbiBvYmplY3RzIGFzIENPTSBvYmplY3RzIGFuZCBnZW5lcmF0ZSBhIHR5cGUgbGli
cmFyeSBzbyB0aGF0IHRoZXkgY2FuIHRha2UgYWR2YW50YWdlIG9mIHRoZSBRdWlja0luZm8gYW5k
IHBhcmFtZXRlciBoaW50cy4NCg0KVElBDQoNCkthcmwgUHV0bGFuZA0Ka3BlcmFjbGVzQGdlb2Np
dGllcy5jb20NCg0K
Python and COM? [ In reply to ]
Rm9yIGEgQ09NIHNlcnZlciBpbXBsZW1lbnRlZCBpbiBweXRob24sIGNhbiBhIHR5cGUgbGlicmFy
eSBiZSBnZW5lcmF0ZWQ/DQoNCkkgd291bGQgbGlrZSB0byBiZSBhYmxlIHRvIGRpc3RyaWJ1dGUg
c29tZSBvZiB0aGUgd29yayBJJ3ZlIGRvbmUsIGJ1dCBtb3N0IG9mIHRoZSBwZW9wbGUgdGhhdCB3
b3VsZCB1c2UgaXQgd291bGQgYmUgdXNpbmcgVkIvVkJBIHNvIEkgd291bGQgbGlrZSBleHBvc2Ug
dGhlIFB5dGhvbiBvYmplY3RzIGFzIENPTSBvYmplY3RzIGFuZCBnZW5lcmF0ZSBhIHR5cGUgbGli
cmFyeSBzbyB0aGF0IHRoZXkgY2FuIHRha2UgYWR2YW50YWdlIG9mIHRoZSBRdWlja0luZm8gYW5k
IHBhcmFtZXRlciBoaW50cy4NCg0KVElBDQoNCkthcmwgUHV0bGFuZA0Ka3BlcmFjbGVzQGdlb2Np
dGllcy5jb20NCg0K
Python and COM? [ In reply to ]
Karl Putland wrote in message <7m9to7$6qg$82@rks1.urz.tu-dresden.de>...
> For a COM server implemented in python, can a type library be generated?

No, but nearly :-) Python has the framework and even some
"proof-of-concept" code, but isnt done.

Feel free to offer to help - not a huge amount of work left given what has
been done already - the pycom-dev mailing archives have the details...

Mark.
Python and COM? [ In reply to ]
> From: Mark Hammond [mailto:MHammond@skippinet.com.au]
>
>
> Karl Putland wrote in message
> <7m9to7$6qg$82@rks1.urz.tu-dresden.de>...
> > For a COM server implemented in python, can a type library
> be generated?
>
> No, but nearly :-) Python has the framework and even some
> "proof-of-concept" code, but isnt done.

Err.. Mark means from within Python. That's not to say you can't build a
type library using an IDL file and MIDL.

Here's an example for the Python.Interperter COM server that exists in
win32com\servers\interp.py.

Unfortuantely, Python.Interpreter needs a slight change inorder to write an
IDL file.
Replace the _public_methods_ line with:
_dispid_to_func = { 1 : Eval, 2 : Exec }
A matching IDL that should work is attached below:
(As an added bonus, this should actually work)
The only GUID from interp.py is the coclass one. Every other GUID was just
generated.
Hope the below helps.... The MIDL docs in MSDN are certainly less than
useful. :(

// System idl include nonsense
import "oaidl.idl";
import "ocidl.idl";

[
uuid(EB048AA4-C2D1-11d2-855D-00C04F797DBA),
helpstring("Python.Interepreter dispinterface")
]
dispinterface IPythonInterpreter
{ properties:
methods:
[id(1)] HRESULT Eval([in] BSTR bstrExpression, [out, retval] VARIANT
pvarReturnValue);
[id(2)] HRESULT Exec([in] BSTR bstrExpression);
};

[
uuid(60240FE4-C2D2-11d2-855D-00C04F797DBA),
version(1.0),
helpstring("Python.Interpreter Type Library")
]
library PythonInterpreterLib
{
importlib("stdole32.tlb");
importlib("stdole2.tlb");

[
uuid(30BD3490-2632-11cf-AD5B-524153480001),
helpstring("Python.Interpreter COClass")
]
coclass PythonInterpreter
{
[default] dispinterface IPythonInterpreter;
};

}

Bill
Python and COM? [ In reply to ]
Bill Tutt <billtut@microsoft.com> wrote:

(posted an cc'ed to bill)

>(As an added bonus, this should actually work)
>The only GUID from interp.py is the coclass one. Every other GUID was just
>generated.

I _think_ the python code would also need to be changed to allow
QueryInterface for the IID of that dispinterface.

>Hope the below helps.... The MIDL docs in MSDN are certainly less than
>useful. :(

Hmmm, yes. Ive checked on MSDN but can't find anything authoritative
on this, either way.

>// System idl include nonsense
>import "oaidl.idl";
>import "ocidl.idl";
>
>[
> uuid(EB048AA4-C2D1-11d2-855D-00C04F797DBA),
> helpstring("Python.Interepreter dispinterface")
>]
>dispinterface IPythonInterpreter
>{ properties:
>methods:
> [id(1)] HRESULT Eval([in] BSTR bstrExpression, [out, retval] VARIANT
>pvarReturnValue);
> [id(2)] HRESULT Exec([in] BSTR bstrExpression);
>};
>
>[
> uuid(60240FE4-C2D2-11d2-855D-00C04F797DBA),
> version(1.0),
> helpstring("Python.Interpreter Type Library")
>]
>library PythonInterpreterLib
>{
> importlib("stdole32.tlb");
> importlib("stdole2.tlb");
>
> [
> uuid(30BD3490-2632-11cf-AD5B-524153480001),
> helpstring("Python.Interpreter COClass")
> ]
> coclass PythonInterpreter
> {
> [default] dispinterface IPythonInterpreter;
> };
>
>}


Toby Dickenson
Python and COM? [ In reply to ]
> From: htrd90@zepler.org [mailto:htrd90@zepler.org]
>
>
> Bill Tutt <billtut@microsoft.com> wrote:
>
> (posted an cc'ed to bill)
>
> >(As an added bonus, this should actually work)
> >The only GUID from interp.py is the coclass one. Every other
> GUID was just
> >generated.
>
> I _think_ the python code would also need to be changed to allow
> QueryInterface for the IID of that dispinterface.
>

Nope. Dispinterfaces are wierd in that they only tell you whats available
via the IDispatch interface. You have to do a QI for IDispatch, not the
dispinterface.

Bill
Python and COM? [ In reply to ]
Thanks for the info everyone.

I think that my first generation I might just release with some docs and =
examples. Then work on the IDL. I signed up on the pycom-dev list... =
I'd love to see this happen. It's so much nicer in Python that C++ or =
VB for creating objects. If anyone knows how far along Christian Tismer =
is with what he was working on, or what's left to be done, I'd like to =
help if I could. I just don't know if I'm ready to play with the big =
dogs yet ;-)

Karl Putland
kperacles@geocities.com

P.S.
Start a big drive tomorrow. I'm moving back to Denver, CO, from AL, so I =
will be gone for a couple of weeks (switching providers, looking for =
broadband, etc...). E-mail to my geocities address will still reach me =
when we get there.

Bye.


Bill Tutt <billtut@microsoft.com> wrote in message =
news:4D0A23B3F74DD111ACCD00805F31D8100DB90F0F@RED-MSG-50...
>=20
>=20
> > From: Mark Hammond [mailto:MHammond@skippinet.com.au]
> >=20
> >=20
> > Karl Putland wrote in message=20
> > <7m9to7$6qg$82@rks1.urz.tu-dresden.de>...
> > > For a COM server implemented in python, can a type library=20
> > be generated?
> >=20
> > No, but nearly :-) Python has the framework and even some
> > "proof-of-concept" code, but isnt done.
>=20
> Err.. Mark means from within Python. That's not to say you can't build =
a
> type library using an IDL file and MIDL.
>=20
> Here's an example for the Python.Interperter COM server that exists in
> win32com\servers\interp.py.
>=20
> Unfortuantely, Python.Interpreter needs a slight change inorder to =
write an
> IDL file.
> Replace the _public_methods_ line with:
> _dispid_to_func =3D { 1 : Eval, 2 : Exec }
> A matching IDL that should work is attached below:
> (As an added bonus, this should actually work)
> The only GUID from interp.py is the coclass one. Every other GUID was =
just
> generated.
> Hope the below helps.... The MIDL docs in MSDN are certainly less than
> useful. :(
>=20
> // System idl include nonsense
> import "oaidl.idl";
> import "ocidl.idl";
>=20
> [
> uuid(EB048AA4-C2D1-11d2-855D-00C04F797DBA),
> helpstring("Python.Interepreter dispinterface")
> ]
> dispinterface IPythonInterpreter
> { properties:=20
> methods:
> [id(1)] HRESULT Eval([in] BSTR bstrExpression, [out, retval] VARIANT
> pvarReturnValue);
> [id(2)] HRESULT Exec([in] BSTR bstrExpression);
> };
>=20
> [
> uuid(60240FE4-C2D2-11d2-855D-00C04F797DBA),
> version(1.0),
> helpstring("Python.Interpreter Type Library")
> ]
> library PythonInterpreterLib
> {
> importlib("stdole32.tlb");
> importlib("stdole2.tlb");
>=20
> [
> uuid(30BD3490-2632-11cf-AD5B-524153480001),
> helpstring("Python.Interpreter COClass")
> ]
> coclass PythonInterpreter
> {
> [default] dispinterface IPythonInterpreter;
> };
>=20
> }
>=20
> Bill
Python and COM? [ In reply to ]
[Re adding typeinfo support to Python COM objects]
> that C++ or VB for creating objects. If anyone knows how far along
> Christian Tismer is with what he was working on, or what's left to be
done.

I dont think Chris got far - he got distracted by stackless Python :-)

There was basically code presented that worked. However, it was not
integrated with the existing win32com code, but instead was split out into
"proof-of-concept". Some ugliness exists, but there was general agreement
(I think) that fixing that required enough work that it may never happen.
The only things remaining were agreement on the attribute names (and we can
assume silence was approval, else we wont get anywhere either :) and an
implementation!

Mark.