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
Consequences of using Py_TPFLAGS_HAVE_GC are incompletely explained #50378
Comments
Creation of GC'd types is explained at The docs claim that PyObject_GC_Track must be called once an object Overall, the docs are missing an explanation of the overall working of |
Can someone in the know provide a doc patch for this? |
Python's extension modules aren't consistent. Some places deallocate the object with PyObject_Del(), other places are using PyObject_GC_Del() or simple Py_DECREF(). |
I concur that this aspect of writing Python types in C/C++ needs better The gcsupport documentation suffers from being written from the perspective I'd appreciate comments/editing suggestions/advice and would welcome the patch -- The Python GC code deals with memory allocation, not with initialization in any The default tp_alloc (PyType_GenericAlloc()) looks at tp_flags, and if Similarly, the GC doesn't care about object destruction. It cares about freeing Thus, most extension writers can get away with 4 simple rules:
And if you really do want a custom allocator, you're screwed anyway, as the |
The Supporting Garbage Collection section of the C API docs has changed considerably since 2009. I suggest closing this as outdated. |
Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.
Show more details
GitHub fields:
bugs.python.org fields:
The text was updated successfully, but these errors were encountered: