gzip.NO_TIMESTAMP sounds like a good idea. But I'm not sure about changing the default behavior. I would prefer to leave it unchanged.
I guess that your problem is that you don't access gzip directly, but uses a higher level API which doesn't give access to the timestamp parameter, like the tarfile module?
If your usecase is reproducible build, you may follow py_compile behavior: the default behavior depends if the SOURCE_DATE_EPOCH environment variable is set or not:
def _get_default_invalidation_mode(): if os.environ.get('SOURCE_DATE_EPOCH'): return PycInvalidationMode.CHECKED_HASH else: return PycInvalidationMode.TIMESTAMP
On Wed, Apr 14, 2021 at 6:34 PM Joachim Wuttke firstname.lastname@example.org wrote:
gzip compression, using class GzipFile from gzip.py, by default inserts a timestamp to the compressed stream. If the optional argument `mtime` is absent or None, then the current time is used .
This makes outputs non-deterministic, which can badly confuse unsuspecting users: If you run "diff" over two outputs to see whether they are unaffected by changes in your application, then you would not expect that the *.gz binaries differ just because they were created at different times.
I'd propose to introduce a new constant `NO_TIMESTAMP` as possible value of `mtime`.
Furthermore, if policy about API changes allows, I'd suggest that `NO_TIMESTAMP` become the new default value for `mtime`.
How to proceed from here? Is this the kind of proposals that has to go through a PEP?
Python-Dev mailing list -- email@example.com To unsubscribe send an email to firstname.lastname@example.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://email@example.com/message/OTUGLATL... Code of Conduct: http://python.org/psf/codeofconduct/