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
The Settings provided to a Protocol are never validated at runtime and incorrect settings can be passed to a Protocol only to cause failures during execution. Since most protocols will require custom settings objects, the types of these settings should be confirmed during instantiation of the Protocols themselves, catching failures early.
Solution
We should add a new class attribute _settings_cls: type[Settings] to the Protocol base class. This attribute should be left unbound. In the Protocol's __init__ method, we can perform the following checks:
Check if the _settings_cls attribute has been defined in the class
Check if the provided settings are an instance of the _settings_cls
If either of these checks fail, raise:
NotImplementedError if _settings_cls is not defined
ValueError if the settings provided do not match the expected type
I've implemented a similar pattern in stratocaster to validate custom settings at instantiation. I believe this approach would be beneficial for Protocols.
Additional considerations
Note that this will break backwards compatibility for existing Protocols.
The text was updated successfully, but these errors were encountered:
Problem
The Settings provided to a Protocol are never validated at runtime and incorrect settings can be passed to a Protocol only to cause failures during execution. Since most protocols will require custom settings objects, the types of these settings should be confirmed during instantiation of the Protocols themselves, catching failures early.
Solution
We should add a new class attribute
_settings_cls: type[Settings]
to the Protocol base class. This attribute should be left unbound. In the Protocol's__init__
method, we can perform the following checks:_settings_cls
attribute has been defined in the class_settings_cls
If either of these checks fail, raise:
NotImplementedError
if_settings_cls
is not definedValueError
if the settings provided do not match the expected typeI've implemented a similar pattern in stratocaster to validate custom settings at instantiation. I believe this approach would be beneficial for Protocols.
Additional considerations
Note that this will break backwards compatibility for existing Protocols.
The text was updated successfully, but these errors were encountered: