[python-win32] Can win32com handle this one?

[Tim Golden]

David Abrahams wrote:
> on Thu Feb 07 2008, Tim Golden <mail-AT-timgolden.me.uk> wrote:
> 
>> David Abrahams wrote:
>>> Is there somewhere a summary of criteria by which I'd choose win32com or
>>> comtypes?
>> Not that I know of. I offer a so-obvious-as-to-be-almost-unneeded
>> list here. It's entirely likely that I've misrepresented things
>> somewhat so I'd be very grateful for additions & editions.
> 
> Thanks, this should be very helpful.  Please see questions below.
> 
>> ==================
>> pywin32 (win32com)
>> ==================
>>

>> PRO: Actively maintained

>> ========
>> comtypes
>> ========

>> PRO: Actively maintained
> 
> That's a biggie.

Note that pywin32 is, as well (obviously, given the fact of
Mark H's response earlier in this thread).

>> PRO/CON: You have to understand more about the way the COM
>> works -- as above this has positive and negative points.
> 
> Hmm, what I've tried to do so far (admittedly not much) didn't seem to
> expose any COM details.  So, like what?
> 
>> CON: You have to do the dirty work yourself; as with ctypes, more
>> scope for crashing Python nastily.
> 
> Really?  Again, what I saw looked like a pretty clean abstraction layer.

Yes, I don't mean to imply that it's crufty or ill-conceived. I
agree entirely that it represents a neat abstraction. All I really
meant was that if you, say, use the shell module from win32com.shell
then someone's done all the work setting up the different interfaces --
IColumnProvider, IActiveDesktop and so on -- and exposing them as
Python objects. You can do the same yourself with comtypes (at least,
I assume you can; I haven't tried) but at the least you have to
fossick around for typelibs and constants and it's one more thing
to maintain. The real nitty-gritty has already been done by Thomas
H in terms of memory access, Pythonic function names and so on.
(And all the more credit to him, may I add!)

TJG