Does the project currently have a stated supported range of Python?
Current State:
The main klippy codebase is 3.3
scripts are 3.6, (though some scripts seem to be trying to do dual 2/3 in a roundabout way that confuses vermin…)
Some specific notable ones:
flash_usb is the only script at 3.6
configfile is soft 3.2, see below for why it is soft
save_variables is a soft 3.0, for the same reason as above.
Also worth noting
util uses a bit dark magic to implement compatibility shims for many python3 changes. if the rest of the project no longer supports py3 entirely, it may be wise to prune this
I’m not sure where you’re getting any of these version numbers. Many people still run Klipper under Python 2, so the minimum version for any part cannot be 3.anything.
They’re from vermin, a SCA tool for determining applicable python versions, with manual verification.
I weeded out the false positives, and cases where the shims in util make things work when they normally would not.
The only hard 3 is flash_usb, and all this is as of 80d185c94c8dbec7f19d791995242af1bb197057
Specifically, it unconditionally references ModuleNotFoundError in call_flashcan, which exists in 3.6+ and not in any 2.
3.3 is the highest detected version for the entire klippy/ subtree, it incorrectly called a few things in there non-2, but those were covered by the shims.
Also worth noting, I didn’t do anything to account for the external dependencies of klippy, they may not solve for some of the versions that the rest of it supports. I don’t know a quick tool for that besides just iterating through, but there’s only 15, so I might run through those in a loop and see.
If it were my project the minimum would be at least 3.6, but it’s not. So far Kevin has not shown any inclination to drop support for 2, and has spent time fixing Python 2-specific issues as recently as September.
If the goal is to maintain py2 support for the klippy runtime (not necessarily the build/flash tooling), that’s fine. I’m just trying to get some clarity here, especially since PR authors can’t adhere to a spec they don’t have.
the scripts/ tree has tons of items with shebangs calling out python3 explicitly, and the Makefile calls many of those. You could probably successfully run the host in a 2.7, 3.3 (remember that 2 and 3 were both codeveloped for some time, so some things are in 2.7 that weren’t in 3.0). Though you’d need !2, 3.6 for everything to work.
Nothing official. The regression test cases will test klippy.py at Python 2.7 and at Python 3.8 (see .github/workflows/klipper3d-deploy.yaml). So that is closest to “official versions” that I know of.
The python requirement of the tools in the scripts/ directory are not well specified. It mostly depends on the author of the tool. In general, if in my own testing I need a tool that doesn’t work on python3, I’ll port it to work on both python2 and python3. There are some notable tools that only work on python3 (such as flash_can.py - note that flash_usb should only fail on python2 if one is trying to use flash_can.py which is python3 only).
If there is code that isn’t working on a newer version of python, then that seems like it would make sense to have a PR that increases the portability across more versions.
I don’t have any immediate plans to drop python2 support. I know that’s not a popular view. My main concern is that python3 syntax changes regularly and frequently causes backwards compatibility problems. So far, limiting the main code to python2 syntax has also been a decent way to achieve compatibility across different python3 versions.
I’ve raised a PR to put @koconnor’s notes above into the docs, and I’ll rework my outstanding PRs to be 2.7 friendly. Looking over klippy’s current dependency set, 3.5 is the lowest common (even though klippy itself is 3.3).