[Python-Dev] Planning on removing cache invalidation for file finders

[Brett Cannon]

On Sun, Mar 3, 2013 at 12:08 PM, Brett Cannon <brett at python.org> wrote:

>
>
>
> On Sat, Mar 2, 2013 at 8:16 PM, Antoine Pitrou <solipsis at pitrou.net>wrote:
>
>> On Sat, 2 Mar 2013 11:16:28 -0500
>> Brett Cannon <brett at python.org> wrote:
>> > > In addition, it may be appropriate for importlib to offer a
>> > > "write_module" method that accepts (module name, target path,
>> > > contents). This would:
>> > >
>> > > 1. Allow in-process caches to be invalidated implicitly and
>> > > selectively when new modules are created
>> >
>> > I don't think that's necessary. If people don't want to blindly clear
>> all
>> > caches for a file they can write the file, search the keys in
>> > sys.path_importer_cache for the longest prefix for the newly created
>> file,
>> > and then call the invalidate_cache() method on that explicit finder.
>>
>> That's too complicated for non-import experts IMHO.
>>
>
> Which is why they can just call importlib.import_module().
>

That obviously should have said importlib.invalidate_caches(). =)

But how about this as a compromise over introducing write_module():
invalidate_caches() can take a path for something to specifically
invalidate. The path can then be passed to the invalidate_caches() on
sys.meta_path. In the case of PathFinder it would take that path, try to
find the directory in sys.path_importer_cache, and then invalidate the most
specific finder for that path (if there is one that has any directory
prefix match).

Lots of little details to specify (e.g. absolute path forced anywhere in
case a relative path is passed in by sys.path is all absolute paths? How do
we know something is a file if it has not been written yet?), but this
would prevent importlib from subsuming file writing specifically for source
files and minimize performance overhead of invalidating all caches for a
single file.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20130303/5e6880bc/attachment.html>