/cc @methane @msullivan @1st1

I'm not actually convinced that _PyObject_GetMethod should be super-internal. For example, Cython literally copied the code of _PyObject_GetMethod from CPython because CPython does not expose it. So maybe we shouldn't actually make it internal.

I expect further optimization which requires changing this API completely.

For general use, I want more high level API for calling method with vectercall.

So, if expected user is only Cython, please keep copying.

So, if expected user is only Cython, please keep copying.

OK, got it.

So, if expected user is only Cython, please keep copying.

I'm probably also going to copy it for mypyc at some point, but I think that falls in the same bucket.

As I send to ML, it seems dllexport doesn't affect calling convention (and calling performance).

It may affects LTO. But I don't think LTO is important here because _PyObject_GetMethod is relatively heavy function.

If there are at least two users (mypyc and Cython), I'm OK to move it to private/.

I'm OK to move it to private/.

What do you mean here? There is a directory cpython/ for the default non-limited API and a directory internal/ for the API that is only defined when Py_BUILD_CORE is defined. Which of the two do you mean?

I'm sorry, there is no private/ directory. As @vstinner said:

Python 3.8 now has a better separation between "private" and "internal" 
APIs:

* private are "_Py" symbols which are exported in the python DLL: they 
should not be used, but can be used techically

* internal are symbols defined in internal header files 
(Include/internal/). Some symbols use PyAPI_FUNC()/PyAPI_DATA(), some 
only use "extern".

So I meant put this API in Include/cpython/object.h, near to _PyObject_GetAttrId.

I will add new really internal API to implement per-opcode cache for LOAD_METHOD,
instead of changing existing _PyObject_GetMethod.

So I meant put this API in Include/cpython/object.h, near to _PyObject_GetAttrId.

OK, done.