-
Notifications
You must be signed in to change notification settings - Fork 6
Reference counting is exposed in the API #12
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
Comments
I presume the issue here is just that |
Note that while the HPy API looks very similar to |
Another difference is that handles must not be compared to determine whether an object |
Someone should conduct a study to check which function calls are commonly followed by Py_INCREF or Py_NewRef. Well, if the C API evolves to move away from borrowing and stealing references, this problem will be solved indirectly, no? |
Existing code should be modified to use the new Py_Is() function to highlight that the code uses this "is" semantics. It doesn't solve the problem, but maybe it will ease the migration to HPy and help other Python implementation to get a similar or same behavior than CPython. PyPy already emulates "is" in the Python language, even if it doesn't have the same implementation for singletons (small integers, empty tuple and string, etc.). |
The "is" problem is also related to CPython implementation of the id() function: return the object memory address. There is no C API abstracting this function by the way, in CPython, you cast a |
I feel that 'is' semantics probably deserve their own issue -- it's an interesting wrinkle of its own. Also thanks to @steve-s for pointing to |
oh, good point! I'd say that adding a C/API function for (unfortunately pypy has the additional problem that the result of |
I've created an issue for "is" and related problems: #37 |
Proposed “revolution” issue: capi-workgroup/api-revolution#7 Unfortunately, fully switching to |
The C-API exposes CPython's choice of using reference counting for memory-management/garbage collection to C extensions by requiring the use of
Py_INCREF
etc everywhere. This is quite costly to emulate for implementations like PyPy and GraalPy that have a different GC strategy. It also constrains CPython's evolution itself, as in the case of immortal objects (see #4).The text was updated successfully, but these errors were encountered: