I think it'll benefit all to keep the discussion objective, or at least
"good subjective"
(https://stackoverflow.blog/2010/09/29/good-subjective-bad-subjective/).
Laments or mutual accusations are only wasting everyone's time,
including the writers.
It's strange that even Guido jumped on the bandwagon -- since he's
supposed to have had lots of experience to tell right away when a
discussion has become unproductive. (Or maybe he's testing us?)
All the material to discuss that we have in this thread is a single test
result that's impossible to reproduce and impossible to run in Py3.
All that this shows is that the PEPs will _likely_ substantially improve
performance in some scenarios. It's however impossible to say from this
how frequent these scenarios are in practice, and how consistent the
improvement is among them. Likewise, it's impossible to say anything
about the complexity the changes will reduce/introduce without a
proof-of-concept implementation. So while this is an argument in favor
of the PEPs, it's too flimsy _on its own_ to accept anything. More and
better tests and/or sample implementations are needed to say anything
more conclusive.
All that was already pointed out, and that's where the thread should
have ended IMO 'cuz there's nothing else to say on the matter.
On 23.07.2018 1:28, Guido van Rossum wrote:
On Sun, Jul 22, 2018 at 1:11 PM, Jeroen Demeyer <j.deme...@ugent.be
<mailto:j.deme...@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
<http://bugs.python.org>. That might give the impression that it's
a more serious thing somehow. Previous optimizations
(https://bugs.python.org/issue26110
<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 <http://python.org/%7Eguido>)
_______________________________________________
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/vano%40mail.mipt.ru
--
Regards,
Ivan
_______________________________________________
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
