Author brett.cannon
Recipients Alexandru Ardelean, Ray Donnelly, barry, benjamin.peterson, bmwiedemann, brett.cannon, dstufft, eric.araujo, eric.smith, eschwartz, vstinner, yan12125
Date 2018-01-15.19:31:35
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <>
Bernhard's idea of SOURCE_DATE_EPOCH being an implicit envvar to forcibly switch on hash-based .pyc files in py_compile is intriguing. I assume this would force the check_source bit to be set? Or since SOURCE_DATE_EPOCH should only be used in build scenarios would you want UNCHECKED_HASH?

As the core dev who seems the most engaged and willing to commit this, I'm willing to make the final decision on this and commit the final PR. I see the options of getting this into 3.7 as the following:

1. SOURCE_DATE_EPOCH acts as an environment variable flag to forcibly generate hash-based .pyc files with the check_source bit set in py_compile and compileall
2. SOURCE_DATE_EPOCH is used to specifically set the timestamp in .pyc files in py_compile and compileall

That's it. No clamping, no changing how timestamp-based .pyc files are invalidated, no touching source files, etc.

If this is going to make it into Python 3.7 then a decision must be made by Friday, Jan 19, so have your opinions on those two options in before then (and in the case of the hash-based solution, would you expect CHECKED_HASH or UNCHECKED_HASH?). At that point I will make a decision and Bernhard can either update his PR or I can create a new one forked from his(I leave that up to Bernhard based on the decision I'll make on/by Friday).
Date User Action Args
2018-01-15 19:31:35brett.cannonsetrecipients: + brett.cannon, barry, vstinner, eric.smith, benjamin.peterson, eric.araujo, dstufft, yan12125, bmwiedemann, Alexandru Ardelean, Ray Donnelly, eschwartz
2018-01-15 19:31:35brett.cannonsetmessageid: <>
2018-01-15 19:31:35brett.cannonlinkissue29708 messages
2018-01-15 19:31:35brett.cannoncreate