>>>> I have comitted an implementation as svn revision 407.
>>>
>>> I took a look. Much better. :-)
>>>
>>> Just one further question: is there any reason why you have the code
>>> inside the generated module to raise an error if the generated number
>>> does not match when you are already performing that check after you
>>> import the module successfully? I think you can quite safely remove
>>> that code. In other words, all you want in the generated code is
>>>
>>> __codegen_version__ = 42
>>>
>>> Then in the importing code
>>>
>>> module = __import__()
>>> if module.__codegen_version__ != comtypes.tools.codegenerator.version:
>>>     raise ImportError("version mismatch")
>>>
>>
>> I think that the version check inside the modules MUST be done.
>>
>> The only purpose of the version checks from outside, in 
>> comtypes.client._generate,
>> is to catch cases where wrappers are already present in comtypes.gen, but 
>> from a previous
>> version that has not inserted version checks into the modules.  Since 
>> comtypes 0.5.1 will
>> probably be the last release that does not generate version checks, this 
>> code can probably go.
> 
> Ah, I see that you are intending to keep the code in the generated
> module and I was intending to keep the code outside the generated
> module. I think we both agree that only one check is needed. :-) The
> only reason I would keep the code outside the generated module is
> "safety" (that code is completely under your control) and "clarity"
> (the code that performs the check is "in your face" when you are
> looking at the code that does the import) -- but I have no difficulty
> with your plans either if you prefer.

I agree that version checking outside would be nicer.  I tried to hack
the comtypes.client._generate module and the codegenerator to implement this,
but there is one place where an outside version check does not work.  For
example, the InternetExplorer typelib generated module contains this statement:
  import comtypes.gen._00020430_0000_0000_C000_000000000046_0_2_0
which imports the stdole2.tlb typelib wrapper code.  So this import is not
done with some code in the _generate module and cannot be checked from there.

> BTW, the code that checks for the existence of the __codegen_version__
> attribute will already confirm anything earlier than 0.5.1 anyway
> since that attribute is new, right?

Yes (if I understand you correctly; I'm not a native english speaker)
it would invalidate modules generated with earlier codegenerator versions.
And this is the only place where an additional outside check makes sense
when otherwise only inside checks were used.  But this problem will
go away after the next comtypes version anyway so maybe the check
can be removed.

-- 
Thanks,
Thomas


-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
comtypes-users mailing list
comtypes-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/comtypes-users

Reply via email to