Showing content from http://mail.python.org/pipermail/python-dev/attachments/20130302/de0a1b0e/attachment.html below:
<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Sat, Mar 2, 2013 at 12:24 PM, Nick Coghlan <span dir="ltr"><<a href="mailto:ncoghlan@gmail.com" target="_blank">ncoghlan@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">On Sun, Mar 3, 2013 at 2:16 AM, Brett Cannon <<a href="mailto:brett@python.org">brett@python.org</a>> wrote:<br>
> On Sat, Mar 2, 2013 at 10:36 AM, Nick Coghlan <<a href="mailto:ncoghlan@gmail.com">ncoghlan@gmail.com</a>> wrote:<br>
</div><div class="im">>> I think you should keep it. A long running service that periodically<br>
>> scans the importers for plugins doesn't care if modules take a few<br>
>> extra seconds to show up, it just wants to see them eventually.<br>
>> Installers (or filesystem copy or move operations!) have no way to<br>
>> inform arbitrary processes that new files have been added.<br>
><br>
><br>
> But if they are doing the scan they can also easily invalidate the caches<br>
> before performing the scan.<br>
<br>
</div>"I just upgraded to Python 3.4, and now my server process isn't see new plugins"<br>
<br>
That's a major backwards compatibility breach, and hence clearly<br>
unacceptable in my view. Even the relatively *minor* compatibility<br>
breach of becoming dependent on the filesystem timestamp resolution<br>
for picking up added modules, creating a race condition between<br>
writing the file and reading it back through the import system, has<br>
caused people grief. When you're in a hole, the first thing to do is<br>
to *stop digging*.<br>
<br>
You can deprecate the heuristic if you want (and can figure out how),<br>
but a definite -1 on removing it without at least the usual<br>
deprecation period for backwards incompatible changes.<br></blockquote><div><br></div><div style>That part is easy: ImportWarning still exists so simply continuing to check the directory and noticing when a difference exists that affects subsequent imports and then raising the warning will handle that.</div>
<div>Â </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
It may also be worth tweaking the wording of the upgrade note in the<br>
What's New to mention the need to always invalidate the cache before<br>
scanning for new modules if you want to reliably pick up new modules<br>
created since the application started (at the moment the note really<br>
only mentions it as something to do after *creating* a new module).<br>
<div class="HOEnZb"><div class="h5"><br></div></div></blockquote><div><br></div><div style>As of right now with the check that's all that is needed, but yes, if the deprecation does occur it would be worth changing it.</div>
</div></div></div>
RetroSearch is an open source project built by @garambo
| Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4