Closed oyarsa closed 1 year ago
Hello there @oyarsa , thanks for posting!
I'd like to understand your use-case better. What's the context where you'd want to allow extra unused values in the configuration file?
My use case is to re-use configuration files between similar-but-not-same scripts. Specifically, I'm working on machine learning scripts, and they tend to have a lot of parameters in common, but some are specific to one program or the other.
For example, I might have separate training and inference scripts. The inference script will share some settings, but not all, with the training script. It's useful to be able to share the same configuration between them.
Ok thanks for clarifying. I'll think about this a little bit, and get back to you.
Once you have a good design for this, I can implement it. My decorator works, but doesn't type well.
Oh btw, you can do this:
from typing import TypeVar
T = TypeVar("T")
def filter_kwargs(cls: type[T]) -> type[T]:
if not is_dataclass(cls):
raise TypeError("filter_kwargs should only be used with dataclasses")
original_init = cls.__init__ # type: ignore
def new_init(cls: type, **kwargs: dict[str, Any]) -> None:
filtered_kwargs = {
f.name: kwargs[f.name] for f in fields(cls) if f.name in kwargs
}
return original_init(cls, **filtered_kwargs)
cls.__init__ = new_init # type: ignore
return cls
Perhaps this will help with the typing a little bit?
That works better, but having the type: ignore
for accessing and setting cls.__init__
is awkward. There must be a better way.
Anyway, this is good enough for now.
Is your feature request related to a problem? Please describe. When using a configuration file and
parse_known_args
, I get an error saying the dataclass constructor does not contain a given parameter. My expectation is thatparse_known_args
would handle these cases. For example, if I have the following code and configuration file:The program fails with this error:
Describe the solution you'd like Unexpected arguments coming from a configuration file should be ignored.
Describe alternatives you've considered I'm currently using the following decorator:
However, I believe this should be handled by the library.