<div dir="ltr"><div>There are some weighty things being said in this subthread that shouldn't be hidden under the heading of improving NamedTuple. For continued discussion of our development philosophy let's open a new thread. (I have an opinion but I expect I'm not the only one with that opinion, so I'll let others express theirs first.)<br><br></div>--Guido<br></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Jul 18, 2017 at 5:13 AM, 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"><span class="">On 18 July 2017 at 05:42, Raymond Hettinger <<a href="mailto:raymond.hettinger@gmail.com">raymond.hettinger@gmail.com</a>> wrote:<br>
> One minor grumble:  I think we need to give careful cost/benefit considerations to optimizations that complicate the implementation.  Over the last several years, the source for Python has grown increasingly complicated.  Fewer people understand it now. It is much harder to newcomers to on-ramp.  The old-timers (myself included) find that their knowledge is out of date.  And complexity leads to bugs (the C optimization of random number seeding caused a major bug in the 3.6.0 release; the C optimization of the lru_cache resulted in multiple releases having a hard to find threading bugs, etc.).  It is becoming increasingly difficult to look at code and tell whether it is correct (I still don't fully understand the implications of the recursive constant folding in the peephole optimizer for example).    In the case of this named tuple proposal, the complexity is manageable, but the overall trend isn't good and I get the feeling the aggressive optimization is causing us to forget key par<br>
>  ts of the zen-of-python.<br>
<br>
</span>As another example of this: while trading the global import lock for<br>
per-module locks eliminated most of the old import deadlocks, it turns<br>
out that it *also* left us with some fairly messy race conditions and<br>
more fragile code (I still count that particular case as a win<br>
overall, but it definitely raises the barrier to entry for maintaining<br>
that code).<br>
<br>
Unfortunately, these are frequently cases where the benefits are<br>
immediately visible (e.g. faster benchmark results, removing<br>
longstanding limitations on user code), but the downsides can<br>
literally take years to make themselves felt (e.g. higher defect rates<br>
in the interpreter, subtle bugs in previously correct user code that<br>
are eventually traced back to interpreter changes).<br>
<br>
Cheers,<br>
Nick.<br>
<span class="HOEnZb"><font color="#888888"><br>
--<br>
Nick Coghlan   |   <a href="mailto:ncoghlan@gmail.com">ncoghlan@gmail.com</a>   |   Brisbane, Australia<br>
</font></span></blockquote></div><br><br clear="all"><br>-- <br><div class="gmail_signature" data-smartmail="gmail_signature">--Guido van Rossum (<a href="http://python.org/~guido" target="_blank">python.org/~guido</a>)</div>
</div>