[Python-Dev] Benchmarks why we need PEP 576/579/580
Guido van Rossum
guido at python.org
Sat Jul 21 19:14:38 EDT 2018
The cost would be if we were to end up maintaining all that code and it
wouldn’t make much difference. Jeroen was asked to provide benchmarks but
only provided them for Python 2. The reasoning that not much has changed
that could affect the benchmarks feels a bit optimistic, that’s all.
The new BDFL may be less demanding though. :=)
On Sat, Jul 21, 2018 at 2:39 PM Stefan Behnel <stefan_ml at behnel.de> wrote:
> 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.
> Python-Dev mailing list
> Python-Dev at python.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Python-Dev