Generalize `to_pyro_random_module` for other PPLs
See original GitHub issuePlease let me know if there is a better way to go about this 😃
A clear and concise description of what you wish to refactor. Please include the following:
We would like to generalize to_pyro_random_module
in order for other PPLs (eg beanmachine) to integrate with gpytorch.
Modules that will be modified
to_pyro_random_module
->to_random_module
- rename
pyro_random_module_cls
prefix from_Pyro
to_Random
- We could potentially upstream and refactor to reduce duplication (eg https://github.com/facebookresearch/beanmachine/blob/main/src/beanmachine/ppl/experimental/gp/__init__.py#L15) at the cost of gpytorch taking a dependency on beanmachine (similar to Pyro)
Impact on code structure
- largely (all except upstreaming the integration in the last bullet) cosmetic, no change in structure
Impact on speed
- n/a
Will this be a breaking change?
- Yes, both library BW compatibility due to renaming functions as well as binary compatibility due to renaming class names
Issue Analytics
- State:
- Created a year ago
- Reactions:2
- Comments:6 (3 by maintainers)
Top Results From Across the Web
No results found
Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start Free
Top Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
My hot take is that people shouldn’t pickle but instead save state dicts.
That makes sense to me. I think in regards to backwards compatibility, we could just keep the
pyro_
versions of the functions as aliases to the newly introduced ones and raiseDeprecationWarning
s.