You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
It would be nice to combine the benefits of hydra.utils.instantiate with OmegaConf.to_object.
Motivation
Currently users of Hydra have several ways to recursively convert OmegaConf objects (DictConfig and ListConfig) into pure python objects:
OmegaConf.to_container converts OmegaConf objects into nested dicts and lists.
hydra.utils.instantiate looks for _target_ fields nested inside an OmegaConf object; _target_ is used to name a specific class to instantiate (or a specific function to call) using the config's fields as parameters.
OmegaConf.to_object recursively converts OmegaConf objects to dicts and lists, giving special treatment to structured configs (which are instantiated as actual instances of the underlying dataclass or attrs class).
The motivation for this feature request has to do with combining structured configs and _target_ keywords in the same config object. Consider the following example:
# main.pyfromomegaconfimportDictConfig, OmegaConffromhydra.utilsimportinstantiatefromschemasimportMainConf, Structured, UnStructuredcfg=OmegaConf.create(
MainConf(s=Structured(x=123), u={"_target_": "schemas.UnStructured", "y": 456})
)
# Neither `instantiate` nor `OmegaConf.to_object` gets the job done:obj=OmegaConf.to_object(cfg)
assertisinstance(obj, MainConf)
assertisinstance(obj.s, Structured)
assertisinstance(obj.u, dict) # field `u` is not converted to `UnStructured`inst=instantiate(cfg)
assertisinstance(inst, DictConfig) # top-level config is not converted to `MainConf`assertisinstance(inst.s, DictConfig) # field `s` is not converted to `Structured`assertisinstance(inst.u, UnStructured)
A Workaround
Combining OmegaConf.to_object with hydra.utils.instantiate often works as expected:
One design question to ask in this context:
When _convert_="object", what if a structured config has a field named _target_?
My instinct is that the config should be instantiated (i.e. _target_ should get called) rather than the config being converted to an instance of the underlying dataclass/attrs class.
pixelb
changed the title
[Feature Request] instatiate(..., _convert_="object") to integrate with OmegaConf.to_object
[Feature Request] instantiate(..., _convert_="object") to integrate with OmegaConf.to_object
Mar 24, 2022
馃殌 Feature Request
It would be nice to combine the benefits of
hydra.utils.instantiate
withOmegaConf.to_object
.Motivation
Currently users of Hydra have several ways to recursively convert OmegaConf objects (
DictConfig
andListConfig
) into pure python objects:OmegaConf.to_container
converts OmegaConf objects into nested dicts and lists.hydra.utils.instantiate
looks for_target_
fields nested inside an OmegaConf object;_target_
is used to name a specific class to instantiate (or a specific function to call) using the config's fields as parameters.OmegaConf.to_object
recursively converts OmegaConf objects to dicts and lists, giving special treatment to structured configs (which are instantiated as actual instances of the underlying dataclass or attrs class).The motivation for this feature request has to do with combining structured configs and
_target_
keywords in the same config object. Consider the following example:A Workaround
Combining
OmegaConf.to_object
withhydra.utils.instantiate
often works as expected:Edge Cases
There are some edge cases that are not handled so well by
to_object(instantiate(...))
:For example things do not work as expected if the
_target_
-config takes a structured config as an argument:Another edge case: calling
to_object(instantiate(...))
does not work if there is a_target_
keyword at the top-level of the config object:Pitch
I propose expanding the
_convert_
parameter toinstantiate
with a new"object"
value, so that callingis almost equivalent to
with special handling of the above edge-cases.
Since calling
OmegaConf.to_object(instantiate(cfg))
handles almost all use-cases, I expect that this feature request will not be of high priority.The text was updated successfully, but these errors were encountered: