Is PY patching a problem (esp. on Windows)

[Avery Andrews]

Armin Rigo's game editor (QuArK) uses PY patching quite extensively for
updates (never PYC), and this problem does not seem to have arisen in
practice, for whatever theoretical reason.  It's a Windows app,
distributed by self-extracting .exe's and .zip files, usng pkzipw, with no
clever settings.

On Thu, 16 Jan 2003, Dennis Reinhardt wrote:

> If I understand correctly , Python looks only at the file timestamp to
> determine whether to re-compile a PY file to create a PYC file.  If so, what
> prevents the following scenario:
> 
> Feb. 2, I release a complete embedded Python hosted program
> Feb 10, I issue a zipped PY patch file
> Feb 13 (a bad day) the user installs and runs the Feb 2 release.  The Feb 10
> patch is applied subsequently.
> 
> It looks to me on Feb 13 that the date of the PY file from the Feb 2 release
> is Feb 2 and the date of the created PYC is Feb 13.  Now the patch is
> applied and the PY file date changes from Feb. 2 to Feb 10.  ... but the
> date of the PYC is later and so it does not get changed.  The PYC file is
> thus out of date.
> 
> On Windows, unzipping a file does not change the file creation date.  This
> scenario may not be a problem under Unix because the PY patch file will
> carry the timestamp of when it was copied, not when it was created.
> 
> I understand the workaround of including a PYC file in the Feb 10 patch file
> (doubling the download size).  I am writing here to see if this is a non-bug
> because I am overlooking something, if it is a bug, or there is another
> solution already in place.  One thing I wonder about and think would be
> useful is if there is a way for a program or running option to suppress
> generating the PYC file in the first place.
> --
> 
> Dennis Reinhardt
> 
> http://www.dair.com
> 
> 
>