bpo-37337: Add _PyObject_CallMethodNoArgs()

[jdemeyer]

CC @methane @vstinner

https://bugs.python.org/issue37337

[vstinner]

I suggest to avoid &self hack. I tried in the past, and it caused me troubles: https://bugs.python.org/issue28858#msg282377

I used such hack in a _PyObject_CallArg1() macro:

#define _PyObject_CallArg1(func, arg) \
    _PyObject_FastCall((func), (PyObject **)&(arg), 1)

"And I expected that the C compiler magically computes the memory address of the argument. But it seems like requesting the memory address of an argument allocates something on the C stack. On x86_64, first function arguments are passed with CPU registers. Maybe requesting the memory address of an argument requires to allocate a local variable, copy the register into the variable, to get the address of the local variable?"

The fix was to remove the macro: https://hg.python.org/cpython/rev/4171cc26272c

[encukou]

@vstinner But in your case, that was not a function argument; it was a macro. Here we have an (inline) function; self should be treated as a number
Do you remember what exactly caused you trouble?

Maybe requesting the memory address of an argument requires to allocate a local variable, copy the register into the variable, to get the address of the local variable?

Is there something wrong with that?
It's essentially what PyObject *args[1] = {self}; spells out.

[vstinner]

I suggest to measure the actual stack consumption. I don't trust compilers anymore ;-)

[jdemeyer]

I suggest to avoid &self hack.

I have a feeling that the problem was because you were using a macro. This would pass a pointer to some object inside the caller. This looks less safe than my version with a static inline function, which does not affect the caller. But I have to admit that this is just a feeling, I cannot explain what went wrong with your earlier attempt at introducing a 1-argument call function.

[vstinner]

I cannot explain what went wrong with your earlier attempt at introducing a 1-argument call function

It wasn't a bug, but just that the macro increased the stack consumption.

[brettcannon]

Code all seems fine, but I'm not enough of a C performance expert to do the final merge.

[jdemeyer]

I suggest to measure the actual stack consumption.

Test code:

from _testcapi import stack_pointer

class D(dict):
    def items(self):
        sp = stack_pointer()
        print(f"stack used: {TOP - sp}")
        return []

mappingproxy = type(object.__dict__)
p = mappingproxy(D())
TOP = stack_pointer()
p.items()

Before: stack used: 912
After: stack used: 640

So at least in this example, stack usage is reduced substantially.

[methane]

LGTM, except PyObject *args[1] = {self}; vs &self issue.
I prefer &self, but both are OK. Please chose one and use it for both of _PyObject_CallMethodIdNoArgs and _PyObject_CallMethodNoArgs.

[jdemeyer]

Please chose one and use it for both

Of course, I just forgot that there were two different functions. Since you and Petr have a preference for &self, I used that.