[Guido] > Yes, I think this is the right thing to do -- either only inherit > tp_free when the GC bit of the base and derived class are the same, Jim is keen to have gc'able classes defined in C get the right deallocation function by magic. In these cases, he leaves tp_free NULL, but indicates gc-ability in tp_flags. tp_base becomes "object" by magic then, and the GC bits are not the same, and neither inheriting object.tp_free nor leaving derived_class.tp_free NULL can work. It seems like a reasonable thing to me to want it to work, so on to the next: > or -- in addition -- special case inheriting PyObject_Del and turn it > into PyObject_GC_Del when the base class adds the GC bit. That's what I had in mind, s/base/derived/, plus raising an exception if a gc'able class explicitly sets tp_free to PyObject_Del (probably a cut-'n-paste error when that happens, or that gc-ability was tacked on to a previously untracked type). If that's all OK, enjoy your vacation, and I'll take care of this (for 2.3 and 2.2.3).
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4