The issue
Configuration has a _post_init method, which is called in from_dict before returning. This means that constructing a Configuration object without using that method (e.g., by calling the default constructor) skips all the crucial logic defined in _post_init.
This should be an extreme case, because using any contructors other than the ones provided in the API should be very uncomfortable for the user. Yet, it is a gap.
To mitigate that, we might utilize dataclass's built-in __post_init__.
The problem with that is a bug in dacite (which we're using for type safety and exception handling), effectively rendering __post_init__ useless when working with dacite. Read more in konradhalas/dacite#244.
The solution
Once the aforementioned bug in dacite is solved, we can easily adapt Configuration.py to work with __post_init__, based on the examples in the formal docs.
Note that this depends on the resolution of the dacite bug. Do not work on this issue before making sure that issue is solved.
The issue
Configurationhas a_post_initmethod, which is called infrom_dictbefore returning. This means that constructing aConfigurationobject without using that method (e.g., by calling the default constructor) skips all the crucial logic defined in_post_init.This should be an extreme case, because using any contructors other than the ones provided in the API should be very uncomfortable for the user. Yet, it is a gap.
To mitigate that, we might utilize
dataclass's built-in__post_init__.The problem with that is a bug in
dacite(which we're using for type safety and exception handling), effectively rendering__post_init__useless when working withdacite. Read more in konradhalas/dacite#244.The solution
Once the aforementioned bug in
daciteis solved, we can easily adaptConfiguration.pyto work with__post_init__, based on the examples in the formal docs.Note that this depends on the resolution of the
dacitebug. Do not work on this issue before making sure that issue is solved.