Remove Deprecation Warning for subnet_kwargs

[stefanradev93]

I would allow users to specify subnet_kwargs indefinitely in inference network interfaces and remove the deprecation warning which was added at some point.

Using subnet_kwargs It is much more convenient when we want to change a single settings from the defaults compared to importing the default MLP, initializing it, and passing it to the network (unwieldly in many respects).

@paul-buerkner @LarsKue @vpratz Let me know what you think before I proceed with a PR.

[paul-buerkner]

I would tend to agree. can you share code of the two options for direct comparison?

[stefanradev93]

Option 1 (subnet_kwargs enabled):

inference_net = bf.networks.FlowMatching(subnet_kwargs={"widths": (256, 256)})

Option 2 (no subnet_kwargs):

inference_net = bf.networks.FlowMatching(subnet=bf.networks.MLP(widths=(256, 256)))

I think we should keep both options as viable (i.e., redundancy is good), especially because defining a whole new network for changing a default hyperparam may be unintuitive for some users.

[paul-buerkner]

Does that create any relevant code overhead apart from one if else statement essentially?

[stefanradev93]

It does entail an additional if statement and serializing the subnet_kwargs.

[paul-buerkner]

Sounds okay to me. I would be in favor of keeping the argument.

[vpratz]

I agree that this is a nice usability feature, and would also be in favor of keeping it. I think from a technical and interface perspective, we should aim to do the following:

• Serialize only the initialized subnet, and not the subnet_kwargs, where possible: Makes simple deserialization possible even if defaults have changed. We might have to give more thought to cases where we use the subnet_kwargs further downstream, I'm not sure about the exact the behavior for those cases.
• If an object instead of a type is passed, warn or error if subnet_kwargs is passed as well.

[stefanradev93]

Currently, subnet_kwargs must be serialized only for CouplingFlow.