[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Python-Dev] Benchmarks why we need PEP 576/579/580

On Sun, Jul 22, 2018 at 1:11 PM, Jeroen Demeyer <J.Demeyer at ugent.be> wrote:

> On 2018-07-22 14:52, Stefan Behnel wrote:
>> Someone has to maintain the *existing* code
>> base and help newcomers to get into it and understand it.
> This is an important point that people seem to be overlooking. The
> complexity and maintenance burden of PEP 580 should be compared to the
> status-quo. The existing code is complicated, yet nobody seems to find that
> a problem. But when PEP 580 makes changes to that complicated code (and
> documents some of the existing complexity), it's suddenly the fault of PEP
> 580 that the code is complicated.
> I also wonder if there is a psychological difference simply because this
> is a PEP and not an issue on bugs.python.org. That might give the
> impression that it's a more serious thing somehow. Previous optimizations (
> https://bugs.python.org/issue26110 for example) were not done in a PEP
> and nobody ever mentioned that the extra complexity might be a problem.
> Finally, in some ways, my PEP would actually be a simplification because
> it replaces several special cases by one general protocol. Admittedly, the
> general protocol that I propose is more complicated than each existing
> special case individually but the overall complexity might actually
> decrease.

So does your implementation of the PEP result in a net increase or decrease
of the total lines of code? I know that that's a poor proxy for complexity
(we can all imagine example bits of code that would become less complex by
rewriting them in more lines), but if your diff actually deleted more lines
than it adds, that would cut short a lot of discussion. I have a feeling
though that that's not the case, and now you're in the defense.

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