A RetroSearch Logo

Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Search Query:

Showing content from https://mail.python.org/pipermail/python-dev/2019-April/156974.html below:

[Python-Dev] PEP 590 vs. bpo-29259

[Python-Dev] PEP 590 vs. bpo-29259 [Python-Dev] PEP 590 vs. bpo-29259Jeroen Demeyer J.Demeyer at UGent.be
Wed Apr 3 11:41:06 EDT 2019
As I'm reading the PEP 590 reference implementation, it strikes me how 
similar it is to https://bugs.python.org/issue29259

The main difference is that bpo-29259 has a per-class pointer 
tp_fastcall instead of a per-object pointer. But actually, the PEP 590 
reference implementation does not make much use of the per-object 
pointer: for all classes except "type", the vectorcall wrapper is the 
same for all objects of a given type.

One thing that bpo-29259 did not realize is that existing optimizations 
could be dropped in favor of using tp_fastcall. For example, bpo-29259 
has code like

     if (PyFunction_Check(callable)) {
         return _PyFunction_FastCallKeywords(...);
     }
     if (PyCFunction_Check(callable)) {
         return _PyCFunction_FastCallKeywords(...);
     }
     else if (PyType_HasFeature(..., Py_TPFLAGS_HAVE_FASTCALL) ...)

but the first 2 branches are superfluous given the third.

Anyway, this is just putting PEP 590 a bit in perspective. It doesn't 
say anything about the merits of PEP 590.


Jeroen.
More information about the Python-Dev mailing list

RetroSearch is an open source project built by @garambo | Open a GitHub Issue

Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo

HTML: 3.2 | Encoding: UTF-8 | Version: 0.7.4