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 opaque fields. For example, we want to be able to serializing the entire IR into a text format, which do not play well with opaque field. Many of the backend passes also need to know all the possible types and field before hand. So one way to view these IR data structures is to view they as typed immutable python objects with fixed slots, where attaching new field is not permitted(that i why I suggested perhaps we should provide a clear error message when user attempted to do so). Such restricted settings are still valid and pythonic(e.g. in the case of namedtuples and others) while also gives us the properties needed for the features in an IR (self-contained, can be round-trip to a text format). --- [Visit Topic](https://discuss.tvm.apache.org/t/round-tripping-objects-through-the-ffi/8440/7) 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/d033cac576d2f9821ec8a406339ea094756c95aa1e00efd14f5b6e036affda18).
