[Tim Golden] >> Presumably, then, if the original COM class exposed, >> say, a .GetGroups method which returned a list of >> groups, each of which you wanted to wrap, in this >> implementation, you'd add a .MyGetGroups method which >> called the original and wrapped the result?
[Ross McKerchar] > It's simpler than that: as long as you've monkey-patched the original > COM groups class, the groups returned by the GetGroups method will > already have your methods: no need to wrap. I see what you mean. As you say, this assumes they're already "victims" of your patching, but I imagine this is usually the case. [Ross McKerchar] > 1) Using your own attributes gets tricky as they pythoncom tries to > automatically assign them to the underlying com object. I've been > bypassing the __setattr__ override by doing "self.__dict__['spam'] = > 'ham'" which would could get tedious rather quickly... You could -- probably -- define a __setattribute__ method, but that would only work if the pywin32-generated classes were new-style (and I doubt they are). > 2) Defining your own __init__ causes all sorts of problems :) > > 3) You "take over" the com classes: that is, comclass.__class__ is your > class, not the original com_class: any kind on explicit introspection > (isinstance, etc.), within pythoncom or existing client code could now > fail. Again a less naive patching process that didn't overwrite > everything blindly should be easy. As you say. Well for the kind of modules I find myself churning out, this looks like an interesting approach, so do report back with pitfalls or... whatever the opposite of pitfalls is! TJG _______________________________________________ Python-win32 mailing list Python-win32@python.org http://mail.python.org/mailman/listinfo/python-win32