Static Type Checking

[sofubi]

Type Checking

As suggested by @kdb424 I'm going to open a draft PR for this so I can get eyes on ahead of making the PR.

Where I'm at so far:

Basically I'm through the modules folder, I've typed out everything I can reasonably in there and moved on up into kmk_firmware.py and the files around it.

Issues I've faced:

I couldn't find type stubs for the adafruit_ble library so I created the ones I needed to get through modules/split.py.
I've added a single stub for micropython's const() function which may need a quick validity check.
Anything I absolutely cannot type (boards.PIN_** for instance) I've typed as Any. In the instance of board.PIN_** I've had to use Any because it's not possible as far as I can tell to actually type those.

What I could use:

Any feedback would be great! I would like to move back through this before submitting and maybe extract some of the really nasty type references out into separate aliases which I've done in a few instances.
Let me know if I'm on the right track with tooling, I've tried to make sure that the pyproject.toml is correctly set up but I do want to verify.

Thanks!

This is fun and thanks for being so available. Really appreciate it. 🙏

[klardotsh]

@sofubi: Damn

This is awesome and I wish I had more words to appreciate this work with, but sometimes a single swear is more than enough, so let's dive in.

1. Is there a way to get these Anys out of here? If there's understanding issues in KMK (or perhaps a lack of documentation to help you type hint this), please reach out to @kdb424 and I, we can almost certainly clear up anything on our end. I noticed a couple Any referring to CircuitPython code; if there's any possible way to tighten these types (even if it's working with @tannewt and co. to push the typedefs upstream), I'd personally be interested in helping that effort even if you don't have the time to do it right now.

2. Would you be willing to add this to our testing and CI framework? Our Makefiile is pretty rusty after years of me ignoring it, but at one point I recall that at least it linted our .py files against Black. Adding typechecking to that Makefile target would be a huge win, and I believe would make it automatically pick up in CI on PR/commit. I'm happy to help as needed here as I believe I'm the only one with extensive knowledge of, for lack of a politer term, all the bullshit I wrote in this regard years ago.

I'll admit that I did a quick skim and not a deep dive - I think these are my main two remarks for now, but I can't guarantee I won't have more thoughts in the future. At the very least, this is a huge start, so thank you for that!

[klardotsh]

I'm dumb, on point 1 I see you talked about the Any craziness. As a stickler in TypeScript for @typescript-eslint/no-explicit-any, whether you or @kdb424 and I take this on (and maybe with help from Adafruit & co.), I'd love to solve that board typedef problem. Any is an escape hatch, and what I've learned from years of TypeScript, Haskell, and these days Rust, is that escape hatches are probably best avoided unless there's a very strong reason.

[sofubi]

@klardotsh going to respond first to the question of adding to the Makefile then to the Anys:

1. Yeah I'd be happy to figure this into the Make pipeline. Once I get everything typed out I'll start working on that and attempting to get the pyproject.toml file configured correctly for that. As far as testing and CI- if the Makefile just picks it up then great! If not I'm happy to work on getting it set up either way.

2. On the topic of the Any typing- my plan currently for the Anys that I've put in for the kmk library I can certainly factor out. I'm happy to work with @tannewt on figuring out a way to type the board module's return of pins. It's an interesting problem and I have a feeling that it's perhaps solved by some simple generic, but not 100% sure there. Any suggestions you or @kdb424 have are always helpful!

Once you have a chance to really dig in let me know if you see any other real offenders that I can clean up. I was pretty careful to jump through the codebase when typing things though so I'm guessing there shouldn't be too many problems (hopefully 🙏 ).

[klardotsh]

I guess the only critical question (that could change the implementation in any significant way) I have right now is: has this code been run on a board with the type hints in the actual source? I was under the impression the PEPs for that syntax haven't been implemented in CircuitPython yet, and that we were gonna need to use the comment-based syntax. Was my assumption incorrect/outdated?

[sofubi]

I need to test this on a board. I have some pm rp2040s that I can test on and some Picos but I haven't had a chance. I did see that MicroPython implements the Typing library but I'm not 100% on if CircuitPython does. Just started a new job so I've been slow on progress here.

…

On Sun, Aug 22, 2021 at 3:12 PM Josh Klar ***@***.***> wrote: I guess the only critical question (that could change the implementation in any significant way) I have right now is: has this code been run on a board with the type hints in the actual source? I was under the impression the PEPs for that syntax haven't been implemented in CircuitPython yet, and that we were gonna need to use the comment-based syntax. Was my assumption incorrect/outdated? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#226 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AEFZIIXHTY6EOF7XXEIUVETT6FDZZANCNFSM5CG6F4DQ> .

[klardotsh]

Absolutely no rush - everything in KMK is at whatever pace the author can healthily handle, no need to burn anyone out. Good luck with the onboarding!

[sofubi]

I was able to test my branch on a Pro Micro 2040 and can confirm that the PEP for the syntax I have been using has not yet been implemented.

I'm going to move to using the comment style syntax and attempt to brush up what's there now as well as move out the uses of Any where they are.