> 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 python-win32@python.org http://mail.python.org/mailman/listinfo/python-win32