This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author ncoghlan
Recipients akvadrako, brett.cannon, eric.snow, ncoghlan
Date 2017-10-13.06:47:07
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1507877227.8.0.213398074469.issue31772@psf.upfronthosting.co.za>
In-reply-to
Content
The problem with changing the bytecode format is that code other than the import machinery reads the bytecode headers, so when we change the format, we need to consider the impact on that code. (Even my multiplication proposal above suffers from that problem)

A freshness check that would avoid the extra stat call, while still making the import system skeptical of the validity of the bytecode cache for just-edited sources would be to also check the source mtime against the *current* time: if they're the same within the resolution of the bytecode format (i.e. 1 second), then compile the code again even if the bytecode headers claims it's already up to date.

That way hot reloaders would be sure to pick up multiple edits to the source file properly, and would reliably be left with the final version loaded, rather than the first version from the final second of edits.
History
Date User Action Args
2017-10-13 06:47:07ncoghlansetrecipients: + ncoghlan, brett.cannon, eric.snow, akvadrako
2017-10-13 06:47:07ncoghlansetmessageid: <1507877227.8.0.213398074469.issue31772@psf.upfronthosting.co.za>
2017-10-13 06:47:07ncoghlanlinkissue31772 messages
2017-10-13 06:47:07ncoghlancreate