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
I don't think serialization would necessarily preclude you from having a 1-1
relation between C++ and Python objects -- deserializing would create a new C++
object so I would not expect that you get back the same Python object. Now I
can see how we would not serialize all stuff people attach t
Thanks @t-vi I agree that keeping the python interface pythonic is one goal we
should strive to achieve. One principle there is to cause less surprises.
In the meantime, we do have the other design constraints, that requires us to
make sure core data structures are self-contained without opaqu
I don't think guarding against specific use cases is more a hack. In the end,
you'll have many funny effects with this type of logic. If you add something to
a set, do you expect the exact object to be in the set afterwards?
In the end, one would need to think about whether having the Python in
However your example code brings up a great point that we should perhaps shoot
a warning when users tries to assign to subclasses of the FFI objects. (perhaps
via overloading setattr or add empty slots to all subclasses)
---
[Visit
Topic](https://discuss.tvm.apache.org/t/round-tripping-ob
I see, if we build a complete function then we can attach the map as an
attribute of the function. But in your case the usage seems to be the
conversion phase. In this case usually map(context) is can be kept as a member
of Mutator(if we make most transformations as member function of that mut
The difficulty with the map is that you need to pass the map around or make it
global state.
My usecase is the PyTorch frontend (which could be made object-oriented instead
of made purely functional to keep track of the map and prelude which is
currently kept track of by indirection). Concrete
In this particular case, because most of the FFI objects are IR nodes, we want
to keep them self-contained. Putting opaque object inside the IR node would
also make things related to the IR harder, such as print the code as textformat.
On the other hand, the need to attach meta-data of specifi
Hi,
I've been implementing graph transformations in Python and sometimes it is
handy to add annotations to nodes. Now, running these through an ExprMutator
will give me all new nodes and they're gone. But actually, they're gone ealier
than that:
```python
x = tvm.relay.var('x', shape=(1,1))
x
