Re: [Python-ideas] PEP draft: Unifying function/method classes
On 2018-04-02 12:39, INADA Naoki wrote:
Which flags in particular do you mean? I just pushed an update explaining the rationale of METH_ARG0_FUNCTION: https://github.com/jdemeyer/PEP-functions#replacing-tp_call-meth_arg0_functi...
And it's very difficult to estimate runtime and maintenance cost of the PEP, without draft implementation.
Runtime cost: the goal is no slowdowns at all. Maintenance cost: IMHO, this PEP simplifies functions in CPython by removing special classes like method_descriptor so the effect should only be in the good sense.
What do you mean? I am not making any changes to METH_FASTCALL. I only mention it in my PEP to document it. Jeroen.
On Tue, Apr 3, 2018 at 12:46 AM, Jeroen Demeyer <J.Demeyer@ugent.be> wrote:
I meant all new flags. Please note that most PEP readers doesn't read calling implementation everyday. So it's unclear why METH_ARG0_NO_SLICE and METH_ARG0_FUNCTION should be added. Actual example for METH_USR* flags are healpful too.
Good.
I can't imagine it until PoC implementation.
When METH_FASTCALL is added, many special casing are added to support it. I'm afraid adding new class means adding more special cases.
On Tue, Apr 3, 2018 at 12:46 AM, Jeroen Demeyer <J.Demeyer@ugent.be> wrote:
I meant all new flags. Please note that most PEP readers doesn't read calling implementation everyday. So it's unclear why METH_ARG0_NO_SLICE and METH_ARG0_FUNCTION should be added. Actual example for METH_USR* flags are healpful too.
Good.
I can't imagine it until PoC implementation.
When METH_FASTCALL is added, many special casing are added to support it. I'm afraid adding new class means adding more special cases.
participants (2)
-
INADA Naoki -
Jeroen Demeyer