[Python-Dev] Benchmarks why we need PEP 576/579/580 (original) (raw)
Stefan Behnel stefan_ml at behnel.de
Sat Jul 21 17:37:05 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 ]
Guido van Rossum schrieb am 21.07.2018 um 22:46:
Given the cost of a mistake here I recommend a higher standard.
May I ask what you think the "cost of a mistake" is here?
Jeroen has already implemented most of this, and is willing to provide essentially a shrink-wrapped implementation. He has shown, using the current application benchmark suite, that his implementation does not degrade the application performance (that we know of). He has motivated in PEP form, and shown in his implementation, that the changes avoid much of the special casing that's currently littered in various spots of the interpreter and replace them by a much clearer protocol, thus reducing the overall maintenance cost. He has layed out a cleanup path to get rid of the current quirks in the split between function/method types, thus making the code easier to explain and lowering the entry barrier for newcomers to the code base. And, he has motivated that this protocol enables a future extension towards a specialised (faster) C level call protocol, which third party extensions would benefit from.
Given all that, I'm having a hard time finding a "cost" in this. To me, it reads like a plain net win for all sides.
Stefan
- 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 ]