Why does @c_class require Python field annotations, but not method declarations?

[Xseventh]

Hi — question about tvm_ffi.dataclasses.c_class.

Right now @c_class(type_key) fails unless the Python proxy class lists all C++ reflected fields in annotations (otherwise it raises “Missing fields … Defined in C++ but not in Python”). But reflected member functions don’t need any Python-side declaration — they just show up.

This feels inconsistent and makes it hard to generate proxies dynamically (I’d like to create a class directly from reflection metadata without manually duplicating the field list).

Is there a design reason for enforcing the annotation check for fields? If not, would you consider an option like a “non-strict / auto fields” mode where:

if Python has no annotations → auto expose all C++ fields

if Python annotates a subset → expose that subset (no missing-fields error)

still error on extraneous fields (typos)

Thanks!

[junrushao]

@tvm_ffi.dataclasses.c_class is currently highly experimental and that's why they are not part of our public APIs: https://tvm.apache.org/ffi/reference/python/index.html.

If you are looking for well-tested stable APIs, tvm_ffi.register_object is likely the go-to option. We have a tutorial regarding registering a C++ class and expose it to Python: https://tvm.apache.org/ffi/packaging/python_packaging.html

• APIs to register C++ class, expose in Python: https://tvm.apache.org/ffi/packaging/python_packaging.html#class
• A automatic tool that generates field/method: https://tvm.apache.org/ffi/packaging/python_packaging.html#stub-generation-tool

[Xseventh]

@tvm_ffi.dataclasses.c_class is currently highly experimental and that's why they are not part of our public APIs: https://tvm.apache.org/ffi/reference/python/index.html.

If you are looking for well-tested stable APIs, tvm_ffi.register_object is likely the go-to option. We have a tutorial regarding registering a C++ class and expose it to Python: https://tvm.apache.org/ffi/packaging/python_packaging.html

• APIs to register C++ class, expose in Python: https://tvm.apache.org/ffi/packaging/python_packaging.html#class
• A automatic tool that generates field/method: https://tvm.apache.org/ffi/packaging/python_packaging.html#stub-generation-tool

I understand that dataclasses.c_class is currently experimental and not part of the public API.

I have one question about roadmap and one about what you’d recommend in my case:

Do you have a rough roadmap / intended direction for tvm_ffi.dataclasses.c_class? Is the goal for it to eventually become a supported/stable public API, or is it expected to remain experimental?

In my project I don’t want to use code generation (e.g. stubgen generating Python source files). I prefer a runtime / reflection-driven approach that materializes Python proxy classes dynamically. In that scenario, would you recommend using c_class, or should I instead build on the stable register_object API and implement my own thin runtime “class materialization” layer?

Thanks!

[junrushao]

tvm_ffi.register_object is indeed the go-to option. Both c_class and register_object share the same C++ API, and register_object's Python API is battle-tested. C++ methods and fields are injected dynamically during runtime.

[junrushao]

Closed due to inactivity - assuming the original ask is already addressed.