[python-win32] Any interest in a pywin32 open session at PyCon?

[Trent Nelson]

> 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.