Is PY patching a problem (esp. on Windows)
Dennis Reinhardt
DennisR at dair.com
Thu Jan 16 00:48:17 EST 2003
More information about the Python-list mailing list
Thu Jan 16 00:48:17 EST 2003
- Previous message (by thread): os.times() for other process
- Next message (by thread): Is PY patching a problem (esp. on Windows)
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
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
- Previous message (by thread): os.times() for other process
- Next message (by thread): Is PY patching a problem (esp. on Windows)
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
More information about the Python-list mailing list