On Tue, Sep 9, 2008 at 12:42 PM, Thomas Heller [EMAIL PROTECTED] wrote:
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___C000_0046_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.
Good point. So adding the code to the generated module makes the most
sense. So I guess you'll remove the code outside of the module, then.
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)
Really? I would never have guessed. Your English is perfectly
understandable to me.
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.
Yes, it can be removed completely -- but only after this release is
considered the baseline and support for all older versions is no
longer being considered. So it may be there for a while
--
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=100url=/
___
comtypes-users mailing list
comtypes-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/comtypes-users
-
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=100url=/
___
comtypes-users mailing list
comtypes-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/comtypes-users
