Fix the issue where passing keyword argumentss was not effective

[DeathlessDogface]

Fix the issue where passing keyword argumentss was not effective, and enhanced the test cases for the _multicall() function

The issue like this:

test code

import pluggy
import pytest
hookspec = pluggy.HookspecMarker("myproject")
hookimpl = pluggy.HookimplMarker("myproject")


class MySpec:
    """A hook specification namespace."""

    @hookspec
    def myhook(self, arg1, arg2):
        """My special little hook that you can customize."""


class Plugin_1:
    """A hook implementation namespace."""

    @hookimpl
    def myhook(self, arg1, arg2=1):
        print("inside Plugin_1.myhook()")
        return arg1 + arg2


class Plugin_2:
    """A 2nd hook implementation namespace."""

    @hookimpl
    def myhook(self, arg1, arg2=1):
        print("inside Plugin_2.myhook()")
        return arg1 - arg2


def test_case():
    # create a manager and add the spec
    pm = pluggy.PluginManager("myproject")
    pm.add_hookspecs(MySpec)

    # register plugins
    pm.register(Plugin_1())
    pm.register(Plugin_2())

    # call our ``myhook`` hook
    results = pm.hook.myhook(arg1=1, arg2=2)
    assert results == [1 - 2, 1 + 2]

test result

(venv) PS C:\Code\DXN4\demo> pytest .\pluggy_demo2.py         
========================== test session starts ============================
        pm.register(Plugin_1())
        pm.register(Plugin_2())

        # call our ``myhook`` hook
        results = pm.hook.myhook(arg1=1, arg2=2)
>       assert results == [1 - 2, 1 + 2]
E       assert [0, 2] == [-1, 3]
E         At index 0 diff: 0 != -1
E         Use -v to get more diff

pluggy_demo2.py:44: AssertionError
--------------------------------------------------------------------------------------------------------------- Captured stdout call ---------------------------------------------------------------------------------------------------------------- 
inside Plugin_2.myhook()
inside Plugin_1.myhook()
======================== short test summary info ============================= 
FAILED pluggy_demo2.py::test_case - assert [0, 2] == [-1, 3]
========================== 1 failed in 0.15s ================================ 
(venv) PS C:\Code\DXN4\demo>

[RonnyPfannschmidt]

I'm torn on this one, as we have a pending design/implementation action for specifically choosen default values (for backward/forward compatibility of hook impl's/specs as parameters are added/removed

part of me wants to formally forbid default values other than None so they can specifically be used to manage addition/removal of parameters in specs/impls

[RonnyPfannschmidt]

note that adding this bit undoes a specifically chosen optimization (that we might want to reevaluate later)

[DeathlessDogface]

Thank you for pointing this out. I understand what you mean. However, the current design has a major limitation that prevents the passing of keyword arguments.

Could you please elaborate on the specific optimization that is being undone by my addition? I would like to understand its purpose and how it was beneficial to the project.

[RonnyPfannschmidt]

initially pluggy used kwarg passing
i'm not quite sure how long ago, but eventually we determined that with extracting only positional arguments, things where much faster (i vaguely recall 2x improvement back in the time)

if we now add kwargs back, that effect is likely undone

as recent python versions have optimizations for calling, i believe a new measurement makes sense

[DeathlessDogface]

Thank you for sharing this information. Could you please elaborate on the performance evaluation method used? I would like to measure the performance based on the new version of Python to have a more accurate comparison. It would be helpful if you could provide more details on the testing environment .

[Cryingmouse]

Hi Ronny,

I also got the same requirement as well.

Any plan to run a new measurement? It is appreciated if anything I can help.

[DeathlessDogface]

I'm torn on this one, as we have a pending design/implementation action for specifically choosen default values (for backward/forward compatibility of hook impl's/specs as parameters are added/removed

part of me wants to formally forbid default values other than None so they can specifically be used to manage addition/removal of parameters in specs/impls

I'm sorry, I just saw this reply. Now I understand the comments in the code, thank you. However, I would still like to recommend my changes to you again.