This change enables persistent Python wrapper objects for Python subclasses of typed, reference counted C++ objects. That means that these objects will store a reference to `self` on the C++ object, and interrogate will always return that instead of making a new Python wrapper every time it is returned from C++.
Practically, this means that you could subclass eg. PandaNode, Event, Fog, what have you, and store these in the scene graph - the Python data in the subclass will be retained and Panda will return your subclass when you ask for the object back rather than creating a new wrapper object without your original data.
To do this, Interrogate generates a proxy class inheriting from the C++ type with additional room to store a `self` pointer and a TypeHandle (which is returned by an overridden `get_type()`). This TypeHandle is automatically created by registering the Python subclass with the typing system. The proxy class is only used when the constructor detects that it's constructing for a subtype, so that regular uses of the C++ type are not affected by this mechanism.
(The registration with the typing system could use some improvement. There's no regard for namespacing right now, in particular. Furthermore, we could move the registration to an `__init_subclass__()` method, with parameters to specify an existing TypeHandle or to customize the type name.)
This creates a reference cycle, which must be cleared somehow. One way this happens is by overriding `unref()` in the proxy, which checks that if the Python and C++ reference counts are both 1, this must be the circular reference, and then it breaks the cycle. Note that this will _only_ work if all other Python references have been cleared before the last C++ reference goes away. For the other case, we need to rely on Python's garbage collector, so these classes also implement tp_traverse and tp_clear.
This commit also therefore re-enables Python garbage collector support (ie. defining `__traverse__()`), which was previously disabled due to the problems caused by multiple Python wrappers referring to the same C++ object. To avoid these problems, Panda will only cooperate with Python's GC if the C++ reference count is 1, in which case we can trivially prove that the last reference must be from the Python wrapper. Note that this explains why we need persistent wrappers for traversal to work--if there are multiple Python wrappers pointing to the C++ object, and they are all participating in a reference cycle, the reference count cannot be 1, and cycle detection does not work. By default, the GC is only enabled for Python subclasses, but a class may define `__traverse__()` in order to opt-in, keeping the previous limitation in mind.
There is a second mechanism introduced by this commit: classes may define a public `__self__` member of type `PyObject *` if they want to use persistent objects even if they aren't being subclassed. This allows these classes to participate in Python's GC and avoid the situation above.
The cycle detection is implemented for PandaNode's Python tags, but this is very incomplete, since the traversal doesn't recurse into children and it won't work if there is more than one wrapper object that is part of a cycle, since PandaNode by default doesn't use persistent wrappers. This problem may need more attention later.
Fixes#1410
This is more idiomatic, simplifies the code, makes it easier to port to eg. HPy later on, and makes it easier to use the limited ABI (where it can be optimized to a tail call) later on
A polyfill is provided for compatibility with Python versions 3.8 and 3.9
Starting with Python 3.12, passing a PyLong into Py_SIZE() triggers an
assertion. PyLong (and the whole C API) is transitioning to be more
opaque and expose fewer implementation details.
Fewer function pointer calls by moving the wrapper creation logic to the downcast function
This also paves the way for some classes to have custom wrapper creation logic
Enabled with `pstats-python-profiler 1`, requires recent version of PStats server.
Currently, it is limited to the main thread only. Support for other threads may be added at a later date.
- `interrogate_function_is_constructor()`
- `interrogate_function_is_destructor()`
- `interrogate_wrapper_parameter_is_optional()`
- `interrogate_wrapper_parameter_is_scoped_enum()`
- `interrogate_wrapper_parameter_is_final()`
Only `interrogate_wrapper_parameter_is_optional()` requires a rebuild of the database with the new changes.
This redoes the handling of `obj[n] = item` to occur in InterrogateBuilder instead so that it doesn't prevent the same remap from being used as getitem.
This fixes the non-const variant of InstanceList[n].
We can't call PyErr_Restore() without a valid thread state, which won't exist in a custom thread if we just called PyGILState_Release(). Not sure how this has ever worked.
* Support converting BitMask types to int
* BitArray constructor accepts a Python long of arbitrary size
* DoubleBitMask (and QuadBitMask, by extension) supports Python long in constructor
* Support for pickling (except DoubleBitMask)
* All of them now properly define __bool__()
* More unit tests
Fixes#886
The intended purpose of this function is to restore an exception
that has already been raised and saved with PyErr_Fetch. It should
not be used to raise new exceptions nor should it be used to clear
the current exception.
The especially egregious example is
`PyErr_Restore(exc_type, nullptr, nullptr);`
as the null value may not be handled correctly.
rdb
Mitchell Stokes
Disyer
Paul m. p. P
WMOkiishi
Leandro (Cerberus1746) Benedet Garcia
Sam Edwards