Re: [python-win32] Bypassing gen_py, accessing makepy-generated class directly

2013-12-17 Thread Mark Hammond
[oops - resend with cc to list] It should be fine if the typelib itself doesn't register, so long as the objects themselves are registered. You should still run makepy over the typelib normally (so the generated file is still in the normal directory), but generating it to its own file should

Re: [python-win32] Bypassing gen_py, accessing makepy-generated class directly

2013-12-17 Thread Mark Hammond
oops 2 :) - where I said -i I meant -o Mark On 17/12/2013 10:13 PM, Mark Hammond wrote: [oops - resend with cc to list] It should be fine if the typelib itself doesn't register, so long as the objects themselves are registered. You should still run makepy over the typelib normally (so the

Re: [python-win32] Bypassing gen_py, accessing makepy-generated class directly

2013-12-17 Thread Jim Bell
Thanks everyone for the info. Generating with -o is fine, needs no fixups that I can tell. I was confusing bypassing the gen_py mechanism (which is possible) with bypassing the entire COM registration (which isn't possible). makepy presents everything pythonishly, but ultimately it still

[python-win32] Bypassing gen_py, accessing makepy-generated class directly

2013-12-16 Thread Jim Bell
I have a somelib.dll/somelib.tlb that doesn't register, and I want to bypass the gen_py mechanism to package it better. I run makepy -o somelib.py. I should be able to instantiate it more directly, not through client.Dispatch(), shouldn't I? Manually wrap it analogously to the server? I see

Re: [python-win32] Bypassing gen_py, accessing makepy-generated class directly

2013-12-16 Thread Greg Antal
Jim: I have code that looks almost exactly like what you've shown. The "makepy - o" process and the import statement are exactly what I do. I would genericize your class instantiation like this: app = somelib.SomeServer(serverStartupParameter1, etc)