On Sun, Mar 3, 2013 at 12:31 PM, Brett Cannon wrote:
> 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 Pat
On Sun, Mar 3, 2013 at 12:08 PM, Brett Cannon wrote:
>
>
>
> On Sat, Mar 2, 2013 at 8:16 PM, Antoine Pitrou wrote:
>
>> On Sat, 2 Mar 2013 11:16:28 -0500
>> Brett Cannon wrote:
>> > > In addition, it may be appropriate for importlib to offer a
>> > > "write_module" method that accepts (module na
On Sun, Mar 3, 2013 at 6:29 AM, Antoine Pitrou wrote:
> On Sat, 2 Mar 2013 18:38:15 -0500
> Brett Cannon wrote:
> > >
> > > You can deprecate the heuristic if you want (and can figure out how),
> > > but a definite -1 on removing it without at least the usual
> > > deprecation period for backwar
On Sat, Mar 2, 2013 at 8:16 PM, Antoine Pitrou wrote:
> On Sat, 2 Mar 2013 11:16:28 -0500
> Brett Cannon 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
On Sat, 2 Mar 2013 18:38:15 -0500
Brett Cannon wrote:
> >
> > You can deprecate the heuristic if you want (and can figure out how),
> > but a definite -1 on removing it without at least the usual
> > deprecation period for backwards incompatible changes.
> >
>
> That part is easy: ImportWarning s
On Sat, 2 Mar 2013 11:16:28 -0500
Brett Cannon 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 whe
On Sat, Mar 2, 2013 at 10:36 AM, Nick Coghlan 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
On Sat, Mar 2, 2013 at 12:24 PM, Nick Coghlan wrote:
> On Sun, Mar 3, 2013 at 2:16 AM, Brett Cannon wrote:
> > On Sat, Mar 2, 2013 at 10:36 AM, Nick Coghlan
> wrote:
> >> I think you should keep it. A long running service that periodically
> >> scans the importers for plugins doesn't care if mo
On Sun, Mar 3, 2013 at 2:16 AM, Brett Cannon wrote:
> On Sat, Mar 2, 2013 at 10:36 AM, Nick Coghlan wrote:
>> I think you should keep it. A long running service that periodically
>> scans the importers for plugins doesn't care if modules take a few
>> extra seconds to show up, it just wants to se
On Sat, Mar 2, 2013 at 10:36 AM, Nick Coghlan wrote:
> On Sat, Mar 2, 2013 at 12:31 PM, Brett Cannon wrote:
> > As of right now, importlib keeps a cache of what is in a directory for
> its
> > file finder instances. It uses mtime on the directory to try and detect
> when
> > it has changed to kn
On Sun, Mar 3, 2013 at 1:36 AM, Nick Coghlan wrote:
> It's that case where the process that added the modules is separate
> from the process scanning for them, and the communication is one way,
> where the heuristic is important. Explicit invalidation only works
> when they're the *same* process,
On Sat, Mar 2, 2013 at 12:31 PM, Brett Cannon wrote:
> As of right now, importlib keeps a cache of what is in a directory for its
> file finder instances. It uses mtime on the directory to try and detect when
> it has changed to know when to refresh the cache. But thanks to mtime
> granularities o
As of right now, importlib keeps a cache of what is in a directory for its
file finder instances. It uses mtime on the directory to try and detect
when it has changed to know when to refresh the cache. But thanks to mtime
granularities of up to a second, it is only a heuristic that isn't totally
re
13 matches
Mail list logo
