AnonymouX47
commented
9 months ago Starting work on the Renderable API (.renderable), I realized the current design, especially of render argument and data namespaces, is very dynamic in nature and just can't be made to work with static type checking (at the moment).
Work on this PR will be on hold pending the redesign of the API in a separate PR. I've thought and planned out most, if not all aspects of the new design but the implementation and particularly, rewriting the tests will still take a while.
imageandwidgetsub-packages as those should go through massive changes real soon, which should come along with static typing.typing_extensionsdependency.mypydev dependency.Adds a GitHub workflow for static type checking with
mypy.Background
I've always been quite on the opposing side concerning this - thus far, annotations have only for documentation purposes - but I've come to realize the potential benefits of proper static type checking, both to the project itself and to its users.
That said, I'm still quite reserved about this as I've also realized this area is quite a slippery slope. It's just a thin line between adequate type hinting for type checking and spending valuable time writing unreadable or non-concise code just to satisfy a static type checker... and I'm not and will never be willing to cross that line (at least, not within this project).
One must understand and always keep in mind that Python is not a statically-typed language and really wasn't designed from the ground to be used that way but I'm willing to employ static typing to the extent that it doesn't result in poorer design, implementation or performance than dynamic typing.
Personally, I tend to play to the strengths of whatever language I use, which in the case of Python (IMHO) is majorly the fact that it's highly dynamic (in most cases) and fosters design and implementation of that kind. I tend to use quite a lot of these aspects of Python where reasonably applicable but will now try to find compromises where and when feasible.