xqdan edited a comment on pull request #8079: URL: https://github.com/apache/tvm/pull/8079#issuecomment-847617680
> thanks for the PR, being able to register ops fully in python is a great tool for prototyping. I have a few concerns for this approach though: > > 1. IMO, we should emphasize this python API strictly for user prototyping and not for any checked in code, since the type function exposed through FFI is not the C++ type relation (it's strictly weaker since we don't have access to the type reporter, and cannot propagate constraints to the inputs, only to the output). We should probably not use "type relation" to describe the python API but I'm not sure what other name to use. Since we still call C++ type relation funcs underhood（such as test_custom_op_infer）, I keep the name but add more comments in python api, is it ok? > 2. Related to the previous point, the python API (at least currently) does not have access to diagnostics for reporting type errors, which is not good for user experience (indeed we're trying to port ICHECKs to diagnostics where possible). > Let me try add a case for python exceptions. > Ideally we should expose all the machinery needed but for prototyping it might not be necessary. cc @jroesch for thoughts -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: [email protected]
