[Python-Dev] Benchmarks why we need PEP 576/579/580 (original) (raw)
Antoine Pitrou solipsis at pitrou.net
Sun Jul 22 16:32:04 EDT 2018
- Previous message (by thread): [Python-Dev] Benchmarks why we need PEP 576/579/580
- Next message (by thread): [Python-Dev] Benchmarks why we need PEP 576/579/580
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
On Sun, 22 Jul 2018 22:11:25 +0200 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.
Two things:
- the issue26110 changes are not very large, it's just two additional opcodes and a bit of support code
- more importantly, issue26110 is entirely internal changes, while you are proposing to add a new protocol (which is like a new API)
Regards
Antoine.
- Previous message (by thread): [Python-Dev] Benchmarks why we need PEP 576/579/580
- Next message (by thread): [Python-Dev] Benchmarks why we need PEP 576/579/580
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]