> 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
> without
> going via an IDL - which would seem much better - if for no other
> reason
> 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
> environment)
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.
Trent.
_______________________________________________
python-win32 mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-win32
