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.)
--Guido On Tue, Jul 18, 2017 at 5:13 AM, Nick Coghlan <ncogh...@gmail.com> wrote: > On 18 July 2017 at 05:42, Raymond Hettinger <raymond.hettin...@gmail.com> > wrote: > > 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 > > ts of the zen-of-python. > > 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). > > Cheers, > Nick. > > -- > Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia > -- --Guido van Rossum (python.org/~guido)
_______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
