Thanks @t-vi . To achieve you are describing we might need to use pyobject as primary container and source of reference counting. Notably due to the design constraint of making Object language invariant we cannot do that. The plus side though is that the object can be access in deployment from other languages.
On the comment of 1-1 relation between c++ and python object. If we indeed restrict the object to be immutable after construction (or simply forbid setting to uknown fields), then we can view it as a 1-1 relation. In such cases two python objects a, b with will come with the same handle (they strictly don't have the same id, but everything else, hash equality and field content all works out). While I understand such restriction loses certain flexibility like attaching opaque information to an object, it does on the other hand improves the clarity and expectation of the IR itself, since we know that there won't be additional information attached and all the info are clearly in the typed field. So the current design rationale comes from both: (1) the complexity to support such feature while retaining language invariance property; (2) The potential desire to keep IR objects cleanly typed and immutable while remaining pythonic as possible. --- [Visit Topic](https://discuss.tvm.apache.org/t/round-tripping-objects-through-the-ffi/8440/9) to respond. You are receiving this because you enabled mailing list mode. To unsubscribe from these emails, [click here](https://discuss.tvm.apache.org/email/unsubscribe/b3b220449447ae13073c5a73be83d49d5162c94e75a2518112bd483319349c4b).
