Summary

By adding and removing types ad-hoc, we now have many types and traits related to describing Python objects. Giving proper names for them will reduce confusions.

Detailed Explanation

• preview: #3630

Types related to managed references

As-is

Giving names to show their relationship will be great. It will be mostly cleared by renaming PyObjectView as Py, by following @coolreader18 's original suggestion when they worked about it.

I additionally suggest to remove PyObjectWeak and just go ahead by its internal type PyRef<PyWeak>, because PyObjectWeak doesn't look like PyRef at all. We mostly handle PyRef in the code, so it will be confusing.

To-be v1

Unfortunately, ur common naming convention implies PyWeakRef is PyRef<PyWeak>. So the left and right side of weak type is not distinguishable by the name. PyRefWeak or WeakPyRef will not be confusing.

To-be v2

PyValue -> PyPayload

By looking back the history, there was PyObjectPayload and PyObjectPayload2 but the latter one is renamed to PyValue. For now, it looks like describing a payload as its past name. We use functions like fn payload(), then fn payload_is() which indirectly based on PyValue through (still alive) PyObjectPayload.

We actually don't have concrete concept of "value".

Drawbacks, Rationale, and Alternatives

Unresolved Questions

Is PyObjectWeak intentionally wrapped as different object to prevent to call PyRef methods?