Specifically, the whole "Option" and counter business. It leads to structures like the following (or did at a time, based on inspection; I guess nothing has changed around this):
I never got an explanation of what the numbers are used for. I think they simply aren't used.
The numbers don't seem to affect the behavior of the app. The user is never asked for one of these numbers, etc. So, it seems the data structure could simply be more like
Something that's been bugging me for a while is this code: https://github.com/fmidue/sd-simulate/blob/a14b38f91e99fffd563f12841a157f164cf4f356/src/state_manager.py#L26-L31
Specifically, the whole "Option" and
counter
business. It leads to structures like the following (or did at a time, based on inspection; I guess nothing has changed around this):I never got an explanation of what the numbers are used for. I think they simply aren't used. The numbers don't seem to affect the behavior of the app. The user is never asked for one of these numbers, etc. So, it seems the data structure could simply be more like
What bugs me further is that the
transitions
global is type-annotated thus: https://github.com/fmidue/sd-simulate/blob/a14b38f91e99fffd563f12841a157f164cf4f356/src/globals.py#L17 which seems to be in disagreement with what the structure above shows. Is the "type checker" not catching this mismatch for some reason?