dspy
dspy copied to clipboard
stanfordnlp
Introduction of incremental mypy compatibility via static typing (where possible)?
Before I dedicate any time to this, I'd like to gauge enthusiasm for introducing static typing (incrementally) to this project.
I'd start by type-annotating the external, user-facing API to increase the quality of life for those devs (like myself) who use IDEs with intellisense/type completions (Pycharm, VS Code) to work with dspy.
Following this, we could incrementally propagate static type hints through the rest of the code base.
For a rationale as to why this is a good idea, check out the mypy docs and pep 484.
I see this was discussed somewhat in #382 as well; seems there is enthusiasm. I would be very interested in assisting in this effort!
What is the "refactor" of which this speaks, though?
I would emphatically agree, as a general rule, that types in software engineering is immensely helpful. I think it goes beyond type annotations, but more of a type discipline in this context. Some of the classes rely overly on kwargs and duck typing, which, as a personal preference, is undesirable. Types are somewhat self documenting and right now it is a little difficult, without spending some time, to understand how the data is flowing in the library and how things are working.
