# \[RFC\] New Python operator registration API **URL:** \ **Category:** Uncategorized\ **Created:** [January 25, 2024, 2:58pm UTC](https://dev-discuss.pytorch.org/t/rfc-new-python-operator-registration-api/1838 "2024-01-25T14:58:13Z")\ **Posts on this page:** 1\ **Showing post:** 4
**Author:** ![gilfree](https://yyz2.discourse-cdn.com/flex036/user_avatar/dev-discuss.pytorch.org/gilfree/32/786_2.png) [@gilfree](https://dev-discuss.pytorch.org/u/gilfree)\ **Post date:** [January 30, 2024, 11:25am UTC](https://dev-discuss.pytorch.org/t/rfc-new-python-operator-registration-api/1838/4 "2024-01-30T11:25:29Z")
Hi, The general approach sounds great, and is simpler then `torch.library` 🙂 There are three things I am missing in this API: 1. (small) Automatic schema deduction from type annotation - In many cases its easy and reduces the effort, and its not hard to verify it against the string like schema. 2. (Maybe out of scope?) Having an option for “native” autograd will be very useful. In my use case I have operators that dynamo cannot handle and cause graph breaks. I want torch.compile to generate a full graph for the forward pass (To have accelerated inference using a custom compiler) but I do not care about the backward speed, and willing to fall back to eager mode for it. I really don’t want to manually write the backward for the operators for these operators. Having something like: 3. (Not sure) Allowing to pass “schema” to the operator. Many operators I use have complex schemas (e.g. quantization schema with multiple config options is selected per layer in the network to give best accuracy). I want to have a way to pass some configuration object. The two options I see now is to serialize to string and deserialize from string (performance? not sure), or to dynamically create a custom op class per configuration (tons of custom ops - almost one per layer) --- _[View the full topic](https://dev-discuss.pytorch.org/t/rfc-new-python-operator-registration-api/1838)._