This is something I am running into while working on an bigger PR (and need to resolve it) and I think it would be good to separately get a quick fix in.
In the ColorAlignment dataclass, the type annotation of custom_color keys (int) does not match the type of the of slots (set of str (which are numeric characters)), which is used to construct the ColorAlignment instance. (The value of that field ends up not the correct type).
Additionally, since this value is saved in the hyfetch.json, serialization for json only supports strings as keys means that the keys go into the json as strs. And it's involved to avoid saving the keys as str. There are outstanding user configs already with serialized string keys. De-serializing those configs also result in str keys in the custom_color field.
I think the resolution is one of the following options:
Change the type annotation to custom_colors: dict[str, int] = ()
Fix the construction of slots to be a set[int], and one of:
a. Enhance the deserialization to generally recognise int str keys.
b. Add a fixup step to ColorAlignment.from_dict
I chose solution 2b here as it is simple and it respects the apparent authorial intent that the custom_colors should be an dict[int, int], which in general makes sense to me. This solution would not in any way preclude smoothly moving to str keys in the future if more slots support is desired with for example letter based slots ${cA} ${cB}.
This is something I am running into while working on an bigger PR (and need to resolve it) and I think it would be good to separately get a quick fix in.
In the
ColorAlignmentdataclass, the type annotation ofcustom_colorkeys (int) does not match the type of the of slots (set ofstr(which are numeric characters)), which is used to construct the ColorAlignment instance. (The value of that field ends up not the correct type).Additionally, since this value is saved in the
hyfetch.json, serialization for json only supports strings as keys means that the keys go into the json asstrs. And it's involved to avoid saving the keys asstr. There are outstanding user configs already with serialized string keys. De-serializing those configs also result instrkeys in thecustom_colorfield.I think the resolution is one of the following options:
custom_colors: dict[str, int] = ()slotsto be aset[int], and one of: a. Enhance the deserialization to generally recognise int str keys. b. Add a fixup step toColorAlignment.from_dictI chose solution 2b here as it is simple and it respects the apparent authorial intent that the
custom_colorsshould be andict[int, int], which in general makes sense to me. This solution would not in any way preclude smoothly moving tostrkeys in the future if moreslots support is desired with for example letter based slots${cA} ${cB}.