[Python-Dev] Benchmarks why we need PEP 576/579/580
Antoine Pitrou
solipsis at pitrou.net
Sun Jul 22 16:32:04 EDT 2018
More information about the Python-Dev mailing list
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 ]
More information about the Python-Dev mailing list