Actually, your further explanation makes sense and I'm happy enough with what you have written now. The further refinement I suggested is not needed. Thanks for taking the time to work this through with me, though.
Anthony On Mon, Sep 22, 2008 at 12:49 AM, Thomas Heller <[EMAIL PROTECTED]> wrote: > [Resending, the first answer seemed to get lost somewhere] > > Anthony Tuininga schrieb: >> > On Thu, Sep 18, 2008 at 10:44 AM, Thomas Heller <[EMAIL PROTECTED]> wrote: >>> >> Thomas Heller schrieb: >>>> >>> Here's the next idea that I have for the version checking: Version >>>> >>> check inside >>>> >>> the generated modules, but using code outside: >>>> >>> >>>> >>> So, inside the generated module: >>>> >>> >>>> >>> ''' >>>> >>> from comtypes import check_wrapper_version >>>> >>> check_wrapper_version('42') >>>> >>> ''' >>>> >>> >>>> >>> comtypes.check_wrapper_version() would compare against the code >>>> >>> generator version, >>>> >>> and in the simplest case raise an ImportError("version mismatch"). In >>>> >>> a more >>>> >>> sophisticated implementation it could regenerate and reload the module. >>>> >>> >>> >> >>> >> I have implemented this now; the code simply compares the actual and the >>> >> required >>> >> version and raises an ImportError if they are unequal. >> > >> > Looks good. >> > >>> >> Also I must admit that I have reintroduced the os.stat() calls on the >>> >> typelib files >>> >> and the generated module files, this is too damn convenient for me. The >>> >> code is much >>> >> simpler now, and if the generated module's timestamp is less than the >>> >> typelib's timestamp >>> >> an ImportError is also raised. If any of the os.stat() calls fail then >>> >> the import succeeds. >> > >> > Hmm, you have added a "coder generator" version inside the generated >> > module. Perhaps you could also add the "type library timestamp" inside >> > the generated module as well and compare that with the os.stat() on >> > the type library? The type library file should always exist, right? >> > Its the module that may not exist or rather be buried inside a zip >> > file. If you put the type library timestamp inside the generated >> > module that would work in both the "script" and "frozen" situations. >> > What do you think of that concept? > > To be honest, the current code does *exactly* what I want: > > """ > def _check_version(actual): > from comtypes.tools.codegenerator import version as required > if actual != required: > raise ImportError("Wrong version") > if not hasattr(sys, "frozen"): > g = sys._getframe(1).f_globals > mod_path = g.get("__file__") > tlb_path = g.get("typelib_path") > try: > mod_mtime = os.stat(mod_path).st_mtime > tlib_mtime = os.stat(tlb_path).st_mtime > except (WindowsError, TypeError): > return > if mod_mtime < tlib_mtime: > raise ImportError("Typelib newer than module") > """ > > On the development machine, the code running as Python script, > 'hasattr(sys, "frozen")' is False, and the timestamps are checked. > Regenerating a module > because a typelib has been recompiled from idl - even if the version number > has not changed - > is what I want; this makes sure that the generated code is correct. > > On the end user machine my code runs from within py2exe, 'hasattr(sys, > "frozen")' is True, > and I do not want to regenerate the code because I trust the typelib version > number in this > case. The generated modules bundled within the executable should be used in > this case. > > There are probably other possible ways to distinguish a developer and an > end-user machine, > if they are preferred. > >>> >> I wonder if there should be a way in comtypes to enable/disable this >>> >> timestamp check? >>> >> Currently I've enabled this code only when a script is run, in other >>> >> words only when >>> >> hasattr(sys, "frozen") is False. >> > > > I was thinking of having a config variable in comtypes\__init__.py so that > users (like you?) > who would like to avoid the os.stat() calls, and who do not compile > typelibaries themselves, > would be able to skip this check completely by changing this variable. Maybe > by editing > a comtypes.cfg file somewhere, maybe programmatically. > > -- 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 > ------------------------------------------------------------------------- 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