Given the state of auto-completion in modern editors, it would be a fairly significant quality of life improvement to add type hints to the API-like portions of the suite, labscript being the obvious primary candidate for usefulness (but not ease).
A few things would need to be decided as far as strategy.
Enforcement: adding type hints without confirming them is just asking for trouble. We'd need to decide a checker (mypy or pydantic, etc) as well as deciding if we would want to automate those checks with actions or just manually check them from time to time. The latter is not common practice, but given how stable the API is, probably not a huge difference in ultimate outcome.
Implementation: presumably we'd want to use a gradual implementation (ie only type hint one submodule at a time, possible thanks to #102)
Minimum python version to support: Since type hinting has been so gradual in python, we'd need to decide what minimum version to support to settle what features we'd actually want to limit ourselves to. Honestly, the more recent the version the better. Py 3.9 is probably a minimum (so we can type hint with list instead of List), 3.10 would be better (for the | Union syntax).
Breaking changes: given the age of the API, I suspect enforcing type hints will lead to breaking changes. We'd need to decide how comfortable we are with that in the name of type hinting.
With regards to the final point. The primary breaking hurdle that I am aware of is the labscript convention of providing the variable name to the constructor to bind instances. IE PrawnBlaster('pb', ...) instead of the more expected pb = Prawnblaster(...). As best I can tell, this is simply to allow us to store that name so it can be checked against by other methods (ie calls like parent_device.name). Pretty sure modern python could allow us to turn name into a read-only property that uses introspection to get the variable name and is memoized for better performance. Downside is that I can't think of a reliable way to maintain backwards compatibility, so a lot of downstream code would have to change.
I personally would be much happier making big breaking changes is we had any semblance of unit tests and if we had any other good reasons to break the API.
Given the state of auto-completion in modern editors, it would be a fairly significant quality of life improvement to add type hints to the API-like portions of the suite, labscript being the obvious primary candidate for usefulness (but not ease).
A few things would need to be decided as far as strategy.
listinstead ofList), 3.10 would be better (for the|Union syntax).With regards to the final point. The primary breaking hurdle that I am aware of is the labscript convention of providing the variable name to the constructor to bind instances. IE
PrawnBlaster('pb', ...)instead of the more expectedpb = Prawnblaster(...). As best I can tell, this is simply to allow us to store that name so it can be checked against by other methods (ie calls likeparent_device.name). Pretty sure modern python could allow us to turnnameinto a read-only property that uses introspection to get the variable name and is memoized for better performance. Downside is that I can't think of a reliable way to maintain backwards compatibility, so a lot of downstream code would have to change.I personally would be much happier making big breaking changes is we had any semblance of unit tests and if we had any other good reasons to break the API.