Repository navigation
Suggestion: Make Python phoenix6 configs classes dataclasses #138
Description
In Python, builder pattern methods tend to be an anti-pattern since Python has keyword arguments.
To give a sense of how unidiomatic this seems to be, here's a snippet from my team's robot code, formatted with a popular autoformatter. Notice how the fluent method call chain isn't particularly readable mixed in with the keyword arguments.
self.chassis_swerve_config = SwerveConfig(
drive_ratio=(14.0 / 50.0) * (27.0 / 17.0) * (15.0 / 45.0),
drive_gains=Slot0Configs()
.with_k_p(7.8294)
.with_k_i(0)
.with_k_d(0)
.with_k_s(0.11742)
.with_k_v(2.3941)
.with_k_a(0.11426),
steer_ratio=(14 / 50) * (10 / 60),
steer_gains=Slot0Configs()
.with_k_p(92.079)
.with_k_i(0)
.with_k_d(1.6683)
.with_k_s(0.086374),
reverse_drive=True,
)It'd be nice if, similarly to the classes in phoenix6.controls, the classes in phoenix6.configs (or at least the config groups) accepted each of its fields as keyword arguments. This feels like a natural job for the dataclasses module, which will autogenerate the __init__ method the obvious way for data transfer objects.
Activity
bhall-ctre commentedon Apr 24, 2026
We will look into this for 2027. Until then, parentheses are an option to improve the readability:
bhall-ctre commentedon Sep 21, 2026
To provide an update, this will be improved in our next release so the following all support named parameters in their constructors:
The parameters will only support being provided by name. Additionally, the optional parameters of control requests will be changed to similarly only support being provided by name (but the required parameters will continue to be supported as positional arguments).