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 brett.cannon
Recipients brett.cannon, erik.bray, pitrou
Date 2013-03-01.22:00:12
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1362175213.81.0.32877130868.issue17330@psf.upfronthosting.co.za>
In-reply-to
Content
So let's see what options we have on the table.

Status quo: picks up mutated modules as long as the mtime is granular enough. Fails in the face of added fails under the same conditions. Need to call importlib.invalidate_caches() to avoid this problem.

Add st_nlinks: Would help in the situation of an added/removed file. Doesn't fix mtime granularity problem. Still might need to call importlib.invalidate_caches() if doing more than adding files.

Drop implicit cache validation entirely: Force people to call importlib.invalidate_caches() no matter what (so no more accidental "it worked on my machine but not that other one"). Cuts down on stat call overhead by 1 per file-based import (which benchmarking suggests doesn't get us anything).

I'm leaning towards just dropping the implicit cache invalidation and forcing people to call importlib.invalidate_caches() when they muck with the underlying modules on sys.path/__path__. This probably would have helped when we started to run into similar problems in the stdlib's test suite when this whole caching mechanism was added. Since this lowers the chance of mistakenly thinking code will work when deployed on other filesystems and speed things up in the majority of cases where people are not dynamically generating files in sys.path.

I don't know if backporting is a good idea, though, as it might catch people by surprise who are not trying to run on different filesystems in 3.3.1. Then again, being lucky in not needing to call importlib.invalidate_caches() doesn't mean that starting to call it properly is a bad thing in a bugfix release.

Re-opening the bug under a different name while we think about this.
History
Date User Action Args
2013-03-01 22:00:13brett.cannonsetrecipients: + brett.cannon, pitrou, erik.bray
2013-03-01 22:00:13brett.cannonsetmessageid: <1362175213.81.0.32877130868.issue17330@psf.upfronthosting.co.za>
2013-03-01 22:00:13brett.cannonlinkissue17330 messages
2013-03-01 22:00:13brett.cannoncreate