cobaya icon indicating copy to clipboard operation
cobaya copied to clipboard

TBD: keeping (or not) "deep" defaults

Open JesusTorrado opened this issue 3 months ago • 1 comments

@cmbant let's see what you think about this:

Let's define the following dicts:

dict_x = {
    "a": "b"
}

dict_y = {
    "a": {
        "b": {
            "b_opt_1": "b_val_1",
        }
     }
}

If dict_x represents the defaults for a class, then recursive_update(dict_x, dict_y) should return dict_y, do we agree? (It fails at the moment; I have an easy fix.)

OTOH, if we invert the roles and dict_y is the default, it is not clear what should happen with recursive_update(dict_y, dict_x): should it keep the internal "b_opt_1": "b_val_1" for the b key/value, or should it drop it and return dict_x? (right now, the latter happens)


To make it a little harder, notice that if we define dict_x in the cobaya-equivalent way:

dict_x_alt = {
    "a": {"b": None}
}

then recursive_update(dict_x_alt, dict_y) == recursive_update(dict_y, dict_x_alt) == dict_y, so there is at least an inconsistency there (recursive_update(dict_y, dict_x) != recursive_update(dict_y, dict_x_alt)), regardless of how we want to treat these "deep defaults".

JesusTorrado avatar Nov 12 '25 13:11 JesusTorrado

The current behavior seems reasonable. Not clear dict_x_alt has to be defined to be equivalent in all cases; e.g. dict_x could be the correct way to override a dict b to be empty that is set non-empty in default; dict_x_alt could be the way to ensure the dict b at least exists and merges if already present.

cmbant avatar Nov 12 '25 14:11 cmbant