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 _______________________________________________ python-win32 mailing list [email protected] http://mail.python.org/mailman/listinfo/python-win32
