[python-win32] Any interest in a pywin32 open session at PyCon?
tnelson at onresolve.com
Sat Mar 15 21:44:18 CET 2008
> I'd be happy to chat about this - but I'm not really sure much
> face-to-face talk is needed (just action ;)
I guess that's what the sprints are for ;-) I'm sticking around 'til Thursday, give or take, and apart from continuing work on the x64 Windows Python build, I'm certainly interested in putting some time into this. (I've booked a session between 6-7pm in 'Love B' (who names these rooms?!) FWIW.)
> Actually, using win32com, we could generate the typelib directly
> going via an IDL - which would seem much better - if for no other
> that it could be used by people without MIDL. So for this reason, @idl
> might not be a good name.
Hmmmm. Would whatever typelib generates be accessible via DumpIDL() in the DLL exposing the Python COM interface? Or is everything done out-of-proc via the pythoncom server? (I haven't ever needed to expose a Python class in COM so I'm not 100% on the details.) Or rather, would your standard run-of-the-mill COM browser be able to view the corresponding IDL?
> Secondly, I seem to recall some other decorator patterns for declaring
> param types and return types - I see no reason we shouldn't try and use a
> generic decorator for this if one exists (which it may not - but its worth
> a look)
> Finally, an issue which may conflict with the above is that we need to
> specify *variant* types, not Python types. eg, what would 'int' mean
> to the typelib? VT_I4? VT_I8? How would unsigned values be declared? What
> would 'list' mean here - VT_ARRAY | VT_VARIANT? How would a list of a
> specific type be declared? Or maybe you are proposing we only support a subset
> of variant types that map directly to python types?
Probably the latter. I do something like that with a @dll decorator that wraps ctypes dlls, e.g.:
@dll(c_wchar_p, returns=c_wchar_p, raiseExceptionOnError=ReadSettingError)
def readSetting(self, setting): pass
i.e. restrict the types to ctypes types. (See http://blogs.onresolve.com/?p=48 for more info.)
Just off the top of my head, I would think that we'd expose all ints/longs as VT_I8 and convert internally. For lists, VT_SAFEARRAY of VT_VARIANTs perhaps (I believe that's how Qt/ActiveQt expose their list classes, e.g. QStringList, QValueList<QDateTime>.) Or for version 0.1, make everything a VT_VARIANT and refine on subsequent iterations ;-)
> ie, in summary: +1 on the idea, but I still see a number of questions.
> > - Using the facilities of dbghelp.dll to allow ctypes to
> > introspect DLLs. I use IPython a lot, once you get a taste
> > for the tab completion facilities, the enhanced console is
> > hard to give up. I'd like to be able to load a cdll in
> > IPython and then use tab to see which methods the DLL
> > exposes. Other perks would be that IDEs could use the
> > information to give completion hints (PyDev etc).
> Sounds fine to me, although its something I have no personal use for. Many
> years ago I tried to allow pythonwin and IDLE, for example, to share some of
> the logic for code completion etc. Much of this also ended up in komodo.
> Sadly though, none of these projects have taken any steps to actually share
> this stuff in an ongoing basis, so I'm not sure there is anything in place
> that would actually make sharing this new code practical (although all these
> other IDEs may well see benefit in forking/porting your stuff to their
Interesting... I'm only semi-interested in the code-completion facilities for IDEs TBH. What I'd really like to do is, heh, introspect say, ws2_32.dll, figure out all the C-exposed methods, then grok MSDN (via BeautifulSoup or whatever) for the method definitions. Grok each type in the C method definition and figure out how to go from Python type -> Windows type (not that hard, that blog post does a simple job of it for raw C types), then do automatic conversion when the cdll methods are invoked. (The MSDN grok -> Python wrapper would be done offline I guess, but the process would be analogous to running make_py on a COM interface.)
The next crack-pot idea I had was leveraging the information in dbghelp.dll to introspect C++ DLLs with exported interfaces. Run depends.exe on any C++ DLL and you get wonderfully decorated descriptions of all class methods, constructors, destructors, even the vtable. Use that to mock Python classes that mimic the C++ classes, where each method calls the corresponding undecorated method in the DLL. And, er, wallah, you have cpptypes. Heh.
More information about the python-win32