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.07:49:54
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1507880995.08.0.213398074469.issue31772@psf.upfronthosting.co.za>
In-reply-to
Content
I wasn't clear on what you meant by "potentially in the future".

Now that I realise you meant "Defer refreshing the bytecode cache to the next import attempt if `int(source_mtime) == int(time.time())`, but still bypass it for the current import", then yes, I agree that would reliably resolve the problem, since all imports during the same second as the edit would bypass the cache without updating it, and the first subsequent import would refresh it a timestamp that's guaranteed to be later than the source_mtime (not just equal).

Brett, what do you think? Such an adjustment to the caching logic should have next to no impact in the typical case where `int(source_mtime) < int(time.time())`, while still making it even less likely that hot reloaders will accidentally cache stale bytecode.
History
Date User Action Args
2017-10-13 07:49:55ncoghlansetrecipients: + ncoghlan, brett.cannon, eric.snow, akvadrako
2017-10-13 07:49:55ncoghlansetmessageid: <1507880995.08.0.213398074469.issue31772@psf.upfronthosting.co.za>
2017-10-13 07:49:55ncoghlanlinkissue31772 messages
2017-10-13 07:49:54ncoghlancreate