Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

bpo-37249: add declaration of _PyObject_GetMethod #14015

Merged
merged 1 commit into from
Jun 14, 2019

Conversation

jdemeyer
Copy link
Contributor

@jdemeyer jdemeyer commented Jun 12, 2019

@mangrisano
Copy link
Contributor

/cc @methane @msullivan @1st1

Include/internal/pycore_object.h Outdated Show resolved Hide resolved
Include/internal/pycore_object.h Outdated Show resolved Hide resolved
@jdemeyer
Copy link
Contributor Author

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.

@methane
Copy link
Member

methane commented Jun 13, 2019

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.

@jdemeyer
Copy link
Contributor Author

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

OK, got it.

@msullivan
Copy link
Contributor

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.

@methane
Copy link
Member

methane commented Jun 13, 2019

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.

@methane
Copy link
Member

methane commented Jun 13, 2019

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

@jdemeyer
Copy link
Contributor Author

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?

@methane
Copy link
Member

methane commented Jun 14, 2019

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.

@jdemeyer
Copy link
Contributor Author

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

OK, done.

@methane methane merged commit b2f9473 into python:master Jun 14, 2019
@jdemeyer jdemeyer deleted the bpo37249 branch June 17, 2019 09:51
lisroach pushed a commit to lisroach/cpython that referenced this pull request Sep 10, 2019
DinoV pushed a commit to DinoV/cpython that referenced this pull request Jan 14, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants