Skip to content

Conversation

@pperanich
Copy link
Collaborator

This is a first pass at removing the requirement that a Unit's SETTINGS and STATE inherit directly from ez.Settings and ez.State, respectively. Instead, for SETTINGS, we ensure the type is a frozen dataclass, and for STATE, we ensure the type is a dataclass.

…State and ez.Settings.

fix: remove accidental import.
@pperanich pperanich force-pushed the refactor-state-settings-check branch from dd2b581 to 336c338 Compare April 22, 2025 22:03
@pperanich pperanich marked this pull request as draft April 22, 2025 22:05
@griffinmilsap
Copy link
Collaborator

@pperanich and I chatted about this PR; it might make sense to redo parts of this PR to not even require dataclasses for state/settings. Some feedback we got from other users indicate that people would like to use Pydantic or Param data structures that enforce bounds on settings, for example. I would like to add additional checks/features if users do choose to use dataclasses, but not require it if they want to try their luck with other data structures.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants