[Python-Dev] Impact of Namedtuple on startup time

[Guido van Rossum]

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 <ncoghlan at gmail.com> wrote:

> On 18 July 2017 at 05:42, Raymond Hettinger <raymond.hettinger at 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   |   ncoghlan at gmail.com   |   Brisbane, Australia
>



-- 
--Guido van Rossum (python.org/~guido)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20170718/17922265/attachment.html>