On 07/18/2017 09:16 AM, Antoine Pitrou wrote: > On Tue, 18 Jul 2017 09:08:08 -0700 > Ethan Furman <ethan at stoneleaf.us> wrote: >> >> Nick Coughlan: >> ------------- > > It is "Nick Coghlan" not "Coughlan". Argh. Sorry, Nick, and thank you, Antoine! >>> As another example of this: while trading the global import lock for >>> per-module locks eliminated most of the old import deadlocks, it turns >>> out that it *also* left us with some fairly messy race conditions and >>> more fragile code (I still count that particular case as a win >>> overall, but it definitely raises the barrier to entry for maintaining >>> that code). >>> >>> Unfortunately, these are frequently cases where the benefits are >>> immediately visible (e.g. faster benchmark results, removing >>> longstanding limitations on user code), but the downsides can >>> literally take years to make themselves felt (e.g. higher defect rates >>> in the interpreter, subtle bugs in previously correct user code that >>> are eventually traced back to interpreter changes). > > I'll reply here again: the original motivation for the per-module > import lock was not performance but correctness. I meant that as an example of the dangers of increased code complexity. -- ~Ethan~
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