Klipper: Python 3

[jeremyherbert]

Hi,

This looks very interesting! Is python3 support planned?

Thanks,
Jeremy

[KevinOConnor]

On Fri, Jun 09, 2017 at 03:52:07AM -0700, Jeremy Herbert wrote:

This looks very interesting! Is python3 support planned?

Thanks.

In earlier revisions, I made the code Python3 compatible and ran some
benchmarks. Unfortunately, those benchmarks showed that Python3 was
measurably slower than Python2.

Some additional Python2 only code has likely been introduced since
that time, but it should not be difficult to make the code support
Python3 again. However, there does not appear to be a compelling
reason to use the slower Python3.

-Kevin

[jeremyherbert]

Would you be happy for me to look into this further? Perhaps you tripped on a bug in python itself, because one would think that python3 should be better (not that I don't believe you of course). I find this host/real time slave paradigm very interesting; I've tried to do something like this in a custom CNC application before, but I unfortunately ran out of time. I'd like to use python3 due to some of the newer features (asyncio, etc) which I would like to use elsewhere, and of course because python2 only has bare minimum bugfix releases.

It might also be useful to set up Travis to protect against any regressions, I can try to give this a go too.

[KevinOConnor]

On Fri, Jun 09, 2017 at 07:12:48PM -0700, Jeremy Herbert wrote:

Would you be happy for me to look into this further? Perhaps you
tripped on a bug in python itself, because one would think that
python3 should be better (not that I don't believe you of course). I
find this host/real time slave paradigm very interesting; I've tried
to do something like this in a custom CNC application before, but I
unfortunately ran out of time. I'd like to use python3 due to some
of the newer features (asyncio, etc) which I would like to use
elsewhere, and of course because python2 only has bare minimum
bugfix releases.

It's not difficult to get Klipper running on python3 - I just did it
as a quick test. (At least enough porting to make batch processing of
gcode files work.) If you're curious, I pushed the changes to a new
work-python3-20170610 branch.

Tests with python3 continue to show around a 10% slow down relative to
python2. That's not a huge deal if there was something in python3
that was important to have.

-Kevin

[dapperfu]

Could something like Numba be used do JIT compiling of the code? You could then really speed up things offloading to a GPU.

https://numba.pydata.org/

What benchmarks are you using to compare Python2 & Python3?

That's not a huge deal if there was something in python3 that was important to have.

Support past 2020?

[lf-]

One of the significant efforts on the part of the Python developers for Python 3 is to improve performance. This is very surprising given http://speed.python.org numbers showing most things being faster in python 3, while getting even faster over time.

But premature optimisation is the root of all evil according to Knuth, so likely a more significant improvement could be made simply by optimising the worst performing codepaths than fiddling around with different interpreters. The entire thing is moot anyway, since one could simply go use PyPy.

[paulie-g]

Perhaps you tripped on a bug in python itself, because one would think that python3 should be better (not that I don't believe you of course).

Python3 being slower in a number of places is a very well-known issue (among people who care about performance) with tons of microbenchmarks to support the case. "Better" != "faster", at least as far as the core devs are concerned apparently. The consensus view seems to be that since hw performance has increased more than interpreter performance has decreased, everything is alright. Without looking at the code, one would assume that in this specific case the issue is integer arithmetic and the way int is implemented in py3.

But premature optimisation is the root of all evil according to Knuth

Knuth is the root of half the performance problems in computing with the other half being abject ignorance and on deeper examination those turn out to be isometric. Knuth's utility at this point rests in teaching beginners algorithmic complexity concepts and no more. The model he uses in his work bears no relation to real hardware. This is why real engineers profile/bench or use more modern (albeit still woefully inadequate) models like RAM if they have to use a model for whatever reason (top tier journals and conferences seem to like them).

The entire thing is moot anyway, since one could simply go use PyPy

The major use case targeted by klipper is running on a pi or pi-equivalent together with octoprint. Pypy needs x86(-64) afaik. The same is true of most other jits and isometric domain-specific equivalents.

and of course because python2 only has bare minimum bugfix releases.

Py2 is a stable and mature codebase, it doesn't need anything more than that. I don't think anyone would argue against python3 having some sexy features, not all of which are backported. I'm a big fan of asyncio which you cite for example, as nearly anyone who has had experience with large codebases using twisted would do, but that's neither here nor there for klipper's use case. Unless Kevin can identify a python3 feature that would be explicitly beneficial, saddling klipper with the burden of maintaining compatibility and the performance hit in exchange for 0 benefit would seem to be unwise.

[paulie-g]

@KevinOConnor Since we're discussing performance (and I happened to glance at the reactor code as a result of this discussion), you don't seem to try to use epoll when it's available unless I missed something.

[dapperfu]

Pypy needs x86(-64) afaik. The same is true of most other jits

Not true at all.

From PyPy's website: We provide binaries for x86, ARM, PPC and s390x running on different operating systems such as Linux, Mac OS X and Windows.

Numba is available (on debian) on amd64, arm64, i86, mips, mips64el, mipsel, powerpc, ppc64, pp64le and s390x.

saddling klipper with the burden of maintaining compatibility

Sticking to Python 2 is saddling it with technical debt on a language that will not be maintained. https://pythonclock.org/

[KevinOConnor]

On Mon, Sep 11, 2017 at 01:28:34AM +0000, Paul G wrote:

@KevinOConnor Since we're discussing performance (and I happened to
glance at the reactor code as a result of this discussion), you
don't seem to try to use epoll when it's available unless I missed
something.

The epoll system call does not improve performance when only a small
number of file descriptors are in use (as is done in the klippy host
code). And, it does not allow registering an fd that is a local file
(which I use extensively in debugging to process gcode files in "batch
mode"). So, for this use case, regular poll() is sufficient and more
flexible.

-Kevin

[KevinOConnor]

On Mon, Sep 11, 2017 at 01:06:28AM +0000, Paul G wrote:

The entire thing is moot anyway, since one could simply go use PyPy
The major use case targeted by klipper is running on a pi or
pi-equivalent together with octoprint. Pypy needs x86(-64)
afaik. The same is true of most other jits and isometric
domain-specific equivalents.

Pypy does work on the RPi, and my initial plans with the project was
to use pypy. Unfortunately, the JIT warmup time with pypy caused
scheduling problems that made the project unusable. Ultimately, to
make the system work, I had to port the latency and performance
sensitive parts of the host software to C code (serialqueue.c and
stepcompress.c). Once that was done, there was no point in using pypy
as regular python was sufficient and more stable.

Separately, FWIW, I don't understand this discussion with python3 vs
python2. As I demonstrated in the work-python3-20170610 branch it is
a ~20 line patch to convert Klipper to python3 instead of python2.
So, for all practical purposes, the code is python3 ready. If there
is a reason to use python3 then I'll use it. Until that time (2020 or
other) I'll continue to use the best tool available.

Cheers,
-Kevin

[paulie-g]

From PyPy's website: We provide binaries for x86, ARM, PPC and s390x running on different operating systems such as Linux, Mac OS X and Windows.

The same website states: "“JIT Compiler” version
These binaries include a Just-in-Time compiler. They only work on x86 CPUs that have the SSE2 instruction set (most of them do, nowadays), or on x86-64 CPUs."

I see references to ARMv6 and ARMv7 jit support in the docs, so perhaps the text on the download page should be read as them merely not providing binaries.

Sticking to Python 2 is saddling it with technical debt on a language that will not be maintained.

As Kevin stated, the patch to enable py3 support is small and can be used if needed. As far as not being maintained, so what? What exactly are you proposing will break as a result? I use a version of tcc in a project that hasn't been touched in nearly a decade and it still works.

[paulie-g]

I don't understand this discussion with python3 vs python2. If there is a reason to use python3 then I'll use it. Until that time (2020 or other) I'll continue to use the best tool available.

It's the "new shiny thing" syndrome. It's everywhere. It's how we ended up with code editors written in javascript running in electron (essentially embedded chromium) and emulating vi with popular plugins and weighing in at 1gb ram. Shiiiny.

As an aside, is there a mailing list or something similar? I'm curious to find out your view on how klipper compares with the likes of Sailfish and what needs to be done to advance it to production-ready status in your view for example, which isn't a good fit for an issue.

[KevinOConnor]

On Sun, Sep 10, 2017 at 08:57:47PM -0700, Paul G wrote:

As an aside, is there a mailing list or something similar?

I hope to have a mailing list setup in the near future. There is a
reprap forum at: http://forums.reprap.org/read.php?147,667655 , but I
don't think it gets much traffic.

-Kevin

[dapperfu]

Do you have a protocol or procedure for benchmarking? I'm just curious as to profiling it.

[KevinOConnor]

On Thu, Sep 14, 2017 at 03:51:02PM +0000, Jed Frey wrote:

Do you have a protocol or procedure for benchmarking? I'm just
curious as to profiling it.

Yes. To benchmark the host software, I process a large g-code file
with the host software in a "batch mode" and time the results - see
docs/Debugging.md for further info. Something like:

time ~/klippy-env/bin/python ./klippy/klippy.py config/example.cfg -i test.gcode -o /dev/null -d out/klipper.dict

For benchmarking the micro-controller software, I connect to the mcu
via the console.py script (also described in docs/Debugging.md) and
send it a series of queue_step commands with a large number of steps.
I re-run this test while decreasing the interval between steps until I
find the lowest interval the micro-controller can step at without
reporting a timing error.

-Kevin

[mamoit]

Python 3.7 brought some nifty speed improvements.
And python 2's sunset is scheduled for the end of next year.
It may be time to redo this benchmark.

[jeroen79]

i would rather see python code replaced with C++

[dragonnn]

i would rather see python code replaced with C++

The Core functions why need good speed are written in C. In other places they is no point replace Python with C/C++.

[jeroen79]

but it couldn't hurt either, not that big a python fan :p , always a hassle.

[dragonnn]

Pretty sure for 99% people is C++ more a hassle then python. We got already so many extra modules created be different people, I don't think it would be so many if Klipper would be written in C++

[ProfDrYoMan]

@KevinOConnor I don't want to open up a new ticket on that.
Just as support for python2 comes to an end. Any real plan to go for python3?
Any investigations what is the performance issue?
Octoprint 1.4 will be capable to run in python3 and I hope that many plugin-devs will also adapt soon.

[ETE-Design]

@KevinOConnor Also would like to know if there is any news about porting to Python 3, cause Python 2 is End Of Life in 2020... OctoPrint is also merging to Python 3 now...

[paulie-g]

End of life doesn't mean your CPython 2.x will explode on Jan 1, 2020. It is as stable and bug-free as it is ever going to be, unlikely to need relevant security-related patches, and will continue to work. If your distro stops shipping a package for it, switch distros or compile yourself.

[ProfDrYoMan]

Debian is transitioning to remove python2. I guess others also.

https://pythonclock.org/
https://lists.debian.org/debian-python/2019/07/msg00080.html
https://release.debian.org/transitions/html/python2-rm.html
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=931659

Quote: "The Debian Python teams are working to push early for reduction/removal
of our python(2) packages with the goal of releasing bullseye with
python3 only."

Yes, you can still compile, install, ... on your own, but why?

[KevinOConnor]

FYI, I remain in a "wait and see" mode. If the major Linux distributions ship without python2 then I will likely update Klipper to use python3 at that point. I have no plans to alter Klipper prior to that.

-Kevin

[ProfDrYoMan]

Ok. 👍
Changing the code base to python3 wouldn't be a big thing as long as there is no plugin interface.
Thanks for the statement.

[ETE-Design]

When OctoPrint remove Python 2.7 you "Will" have to move to another Distro, or follow Them :-)

[dapperfu]

@ETE-Design

When OctoPrint remove Python 2.7 you "Will" have to move to another Distro, or follow Them :-)

Only if there is a direct OctoPrint/klipper linkage. The way my setup is setup is klipper opens a fake printer that OctoPrint talks to. They're both communicating through GCode so there's compatibility issues.

If the major Linux distributions ship without python2

Sid has an open ticket.

Ubuntu 20.20 is planning on removing it.

Fedora will support it until the sun goes cold for the same reason COBOL exists, their customers will pay to not have to do work.

[JohnEdwa]

Most likely a majority of Klipper and Octoprint instances run on a Raspberry Pi and most of them will run Raspbian, which is based on Debian. So for Klipper, that is probably the main one to keep an eye on.

Although Debian does say that Buster supports both Python 3.7 and 2.7 and as it was just released, unless they radically change their release schedule that has been stable for almost 20 years, Bullseye should still be good two years or so in the future dropping somewhere around 2021-07.

[celogeek]

I tried octoprint 1.4 on python3 and the interface is pretty fast. Can't we have a klipper code that run on python2 and 3 so people can choose?

[luqasz]

python2 won't always be on debian/raspbian as more and more code is migrated. IMO better to start porting code then be stuck with unsupported version.

[jakep82]

Separately, FWIW, I don't understand this discussion with python3 vs python2. As I demonstrated in the work-python3-20170610 branch it is a ~20 line patch to convert Klipper to python3 instead of python2. So, for all practical purposes, the code is python3 ready. If there is a reason to use python3 then I'll use it. Until that time (2020 or other) I'll continue to use the best tool available. Cheers, -Kevin

Not sure I understand all the fuss. Python2 is still available on almost all stable distros, and it's included on the most common install target which is OctoPi. Kevin has already indicated it's a fairly minor patch to convert to python3, and when python2 is dropped he'll make the move. Until then, why would we want to sacrifice performance?

[luqasz]

Until then, why would we want to sacrifice performance?

In 2017 you had python 3.5 as I presume. Now you have 3.8.

• Python past 3.5 has multiple performance improvements. Example, dicts are faster and ordered and others.
• Python 2 is available and EOL, which bring couple of consequences:
  libraries drop support for python 2 and will not fix bugs, add new features.
  If any bug is found, it will not be patched. Unless you are RedHat ;)
• In python 3.6 you have await and async with asyncio and trio libraries. Klipper relies on IO talking to micro controller.

Your call. You'r the maintainer.

Cheers.

[altendky]

Supporting Python 3 isn't about Python 2 suddenly poofing out of existence. Even if you want something that's maintained, you still have pypy2. It's about being in a community that is significantly supported. Having libraries that are maintained. Not leaving users stuck using unsupported tools. This isn't the sort of thing that is immediately a big deal but as time passes it will get to be more and more of an 'ugh, here is another embedded app that we have to jump through legacy hoops to keep barely running'. And if it's really 20 lines of code to tweak to be compatible with both...

But, I'm not a user nor a contributor (at this point). I'm just someone that was trying to help someone else that was going to have to deal with pain because they wanted to develop something but (at least thought they) were being held back to Python 2 because of Klipper.

I see that @jed-frey did an update but it's hard to look at regarding py2 vs. py3 because it's flooded with py3.6+ f-string conversions. Everyone has .format() and % formatting so that's not really part of a 2 to 3 conversion nor a switch to 2/3 polyglot. Also, 3.5 is still not EOL so f-strings are more limiting than they need to be for a py3 project.

[mfp20]

I'm a micropython's fan :)

[Salamandar]

@KevinOConnor Any news/changes ? :)
Octoprint moved to py3 in their last version.

[celogeek]

Octoprint or klipper are two different things. It is 2 tools that communicate together.
I think even if octoprint uses python 3 it is not a problem to have klipper that uses python 2.

Am I missing anything?

[Salamandar]

No, no, you're completely right.

What I meant is that, usually Klipper is used with Octoprint, (often on Octopi), so that'd be great to use the same Python version.

[goeland86]

Last update from @foosel on the youtube live stream was that at the moment, OctoPrint 1.4.x runs on python3 >3.5, but octopi doesn't ship with it yet. Nor are 77% of plugins marked as python3 compatible by their maintainers. There will be a beta of Octopi which uses python3 instead of python2.7 coming soon.

FWIW, I'm working on building a ready-to-run image that combines Klipper & OctoPrint for Beaglebone + Replicape. Both get their own venv. Octoprint will be using python3.7, and Klipper 2.7 until @KevinOConnor clearly states he's switching to use python 3.x instead.

[foosel]

Just a minor correction to this: OctoPi actually does ship with Python 3, but the virtual environment for OctoPrint on it is still Python 2. So Python 3 is available on OctoPi, it's just not yet used by OctoPrint (one, because I cannot retroactively change the image, two, because I don't want to mess with the virtual environment as part of the update since that's just a recipe for disaster, and three, since the plugin ecosystem simply isn't there yet).

[GarthSnyder]

Another potential plus for Python 3 is that there's a piwheel (precompiled binary) available for numpy and related numeric packages. numpy itself supports either version of Python, but piwheels only serves builds for Python 3.

I don't know that there's necessarily a must-have application for these libraries in Klipper right now, but they do make it trivial to manage, slice, and reshape vectors and matrices. I've run across Klipper code in multiple places that made me think "Hmm, this might be simpler and clearer expressed in numpy."

[onovy]

we (Debian) are in process removing of Python 2. For progress, see: http://sandrotosi.me/debian/py2removal/py2removal_progress.png

There is high chance there will be no Python 2 in next Debian and thus Raspbian release.

It's time to migrate, really :)

[paulie-g]

No one uses Debian anymore unless they have to. Variants of Raspbian with python2 support, or a repo with it available, will be forthcoming no doubt to address this braindead silliness. Please stop pretending that anything Debian does ought to have a deciding influence on independent projects, especially ones targeted at embedded use cases, since you've demonstrated a complete disregard for that use case. Which is amusing, given that Debian still has some relevance there since people didn't foresee it turning into a basketcase years back when they chose to base off it.

Klipper is targeted at a limited number of particular hw configs on dedicated devices. Unless you're claiming existing versions of Debian and derivatives will magically self-immolate and stop working, this 'zomg, pay attention to US, we're removing!!' is FUD, plain and simple. [/not intended as a flame]

[goeland86]

@paulie-g while I understand you're just trying to shove back against the push from the Debian organisation, you're actually incorrect in assuming that Debian moving forward will not have consequences for the community.

For my part, building images for the Replicape/Beaglebone Black combo, I'm using a beaglebone debian 10.3 image as a base.

Further, Python3 (>3.5) actually brings general performance improvements over Python2. That's a fact. And for embedded systems where resources matter (like a Beaglebone), that performance gain is highly desirable.

So yes, wanting to move new releases of Klipper to Python3 is something that I would very much encourage. Not in an emergency, but in a planned fashion as part of the next set of features to be released.

The fact that Debian - a community that has a reputation about moving about as fast as glaciers - has decided to do that same move should tell you in no uncertain terms that the change will bring about net positives for any software stack being built that isn't built on an OS from at least 5 years ago.

[paulie-g]

I have no animus towards Debian. Fact is, if Debian took their role as upstream of Raspbian seriously, they wouldn't be doing this because that's something you don't do in embedded. I get that they don't have to care about downstream distros and have to do what's right for their desktop case (my personal dislike of their recent decisions notwithstanding), but expecting others to ask how high when they say to jump is a bit too much.

This has all been discussed before. Python3 is not faster across the board (unless you are familiar with CPython internals, please don't quote useless microbenchmarks someone else did). There may well be speed regressions and in a timing-sensitive application like Klipper, this matters. In fact, in a timing-sensitive application any change in performance might be negative - I can't tell you how many times I've seen performance improvements uncover bugs, say races that were not possible previously as an example.

Klipper as it stands has been thoroughly tested. Klipper with an update to python3 is a completely unknown quantity that may well produce more print failures. Since there is currently no round-trip timed regression test suite, this is essentially Schroedinger's cat carrying ebola. It can not be magically assumed to be better. I'm not familiar with the code so can't say categorically myself, but if this were trivial, Kevin would've done it already.

Debian has a slow release schedule. That is not the same as being immune from precipitous silliness. Given the dysfunction of that project (much as I respect its place in history), what they do ought to, at best, make no difference to anyone else's decisions. Fundamentally, even if it were still the golden standard in administration and decision-making, what a general-purpose desktop distro does in an EOS situation has more to do with policies about not shipping (security-) unsupported code as part of the base system than with whether something makes technical sense, especially for embedded.

There is a reason embedded is usually frozen once it ships bar crucial updates. This is not one of them. Kevin may choose to do something with python3 or he may not, but it will have nothing to do with a) clueless whinging in an issue thread asking for it 'just because' or b) upstream desktop distro doing something. Since custom images are being made, like yours, the latter ought to be a complete non-issue.

[goeland86]

@paulie-g clearly someone hasn't read what @KevinOConnor wrote above:

As I demonstrated in the work-python3-20170610 branch it is
a ~20 line patch to convert Klipper to python3 instead of python2.
So, for all practical purposes, the code is python3 ready.

And as to micro-benchmarks etc. please do remember that I am working with an embedded platform, and I've witnessed first hand how using OctoPrint with Python3 instead of Python2 on a single-core ARMv7 chip actually drastically reduces startup time and improves responsiveness.

What I'm asking is to reconsider the decision that was made about Kevin's "wait and see" approach, now that upstream and other distros _will be_ removing python2 as the default or entirely from the repositories.

@paulie-g if your embedded application is so monolithic and badly built that it cannot run on a more efficient system, you should be re-writing in a way that removes the inadequacies this uncovers, not blame upstream. This is why you have dev, test and production system distinction. With embedded this may simply be 3 branches of the code to maintain that you switch between to test patches & reliability.

[altendky]

Maybe there is a way that py3 support could only be beta or alpha or somesuch? But wow to this application being so time sensitive but still written in python? I really wish in general that the topic of py2 and py3 could be discussed without not-flaming (referring not just to here). And I'm not clear how 'the world is moving on and won't be offering the interpreter' is 'just because'. At first you can just compile yourself. The compilation requirements start having to be handled specially. Then it becomes this convoluted mess. There are of course reasons for how embedded is handled. There are also super time eating results of it. It seems pretty obvious that py2 support should remain. Unless a new application is going to be written as a replacement it's not obvious why py3 support should be totally avoided.

One part of the detail of embedded not changing is that at some point you do. Upstream items become unavailable. Even when you select those with guaranteed availability it is only for a certain time, maybe ten years or whatever. When that's up, you better have prepared because you will be changing. You can keep buying random stock but at some point that runs out too. We aren't there with py2. But, we've been warned multiple times and indications are that availability is being reduced. The pain will slowly grow, regardless of whether py2 is technically superior in any given way or for any given application. In hopes of not being taken as a py2 hater, I've been happy in much of my open source work to continue enabling use of libraries in py2.

I dunno... :|

[DanielJoyce]

Ubunto 20.04 no longer ships with python defaulting to python2.x

pip is now warning that python2 support will soon be dropped.

Found this out manually installing octoprint on my Ubuntu Server loaded Rasp pi4.

[Salamandar]

Fedora just dropped Python2.

[Salamandar]

@paulie-g So are you saying you're afraid that using Python3 will uncover bugs and unhandled race conditions ? Well, I'm gonna stop using Klipper, even in Python2, if that's the case…

[onovy]

Jinja2 (Klipper dependency) is going to drop Python 2 support in major release 3.x

[celogeek]

Anyone has try to do a fork, patch with python 3 support, and test it will real printing?
Did you see anything wrong about it?

[DanielJoyce]

Also the concern about encode/decode is minor. If you decode 'ascii' it basically just gives you the raw bytes. Afaik all the serial protocols for printer are ascii.

[DanielJoyce]

And if you are worried about performance, and using python 2, well. Those two words don't go together, though I find python faster than ruby. :)

[Salamandar]

@KevinOConnor
AFAIK, making the py2 code compatible with py3 doesn't have any "drawbacks".
So, why not just "shut the mouth" of people like us by making the code compatible py2/py3, but still saying py2 is the official supported version ?

[DanielJoyce]

Of course, you can compile Python to C now, so I mean, not as fast ( GC and all that ) but faster still.

[onovy]

https://www.jetbrains.com/lp/python-developers-survey-2019/

Only 10 % of users are using Python 2 instead of Python 3.

[DanielJoyce]

Well if klipper is that time sensitive, don't use python. GC does not play well with hard realtime. But then all klippy does is parse gcode and stuff buffers with mcu commands. It seems to behave just fine.

That said, python2 is going the way of the dodo, quite rapidly. Eeventually even rpi will move off kernel 4 to more modern kernels and releases. Personally ubuntu server runs just fine on mine rpi4.

[DanielJoyce]

As for speed, it looks like py3 has sped up a lot, and will only get faster. There will never be any more speed improvements to 2.7

https://hackernoon.com/which-is-the-fastest-version-of-python-2ae7c61a6b2b

The only gotcha is Crypto.

[DanielJoyce]

Just ran the 2to3 tool, didn't see anything MAJOR. Have yet to run it to test, but the vast majority of it is around print() and some list stuff.

[SidShetye]

@KevinOConnor : Could you please reopen this issue for Python 3? Most other issues requesting it have been closed as duplicates and this is the primary issue, so (IMHO) should be kept open till release. The rest of the thread already makes a very good case addressing warnings, deprecation, level of efforts etc. so I won't repeat that. The 'newest' warning is that PIP will drop Py2 in 6 months, so considering porting, testing, documentation and spreading awareness, this should be completed yesterday :) !

PS: I really dig Klipper's design separating low level printer configuration from the firmware.

[masc2279]

Using Octoprints script Klipper plug in seems to not work after migration .... this Klipper module still may need to be updated to python 3 .... If so this Should ticket should be re opened.

[DanielJoyce]

Octoprint Klipper plugin not a part of Klipper, that issue should be opened on their repo.

[danielfmo]

Using Octoprints script Klipper plug in seems to not work after migration .... this Klipper module still may need to be updated to python 3 .... If so this Should ticket should be re opened.

You can take a fork from the original plugin (what I did) or update octoprint config to disable python validation on that plugin.
I'm running Octoprint and Octoklipper with python 3.7 for months with no problems

[goeland86]

Leaving aside the plugin, Python3 is now well established as the only python language moving forward.

@KevinOConnor if you're not planning on migrating to Python3, what are your plans for Klipper? We're past the stage where a significant portion of the user base can accept a "wait and see" answer. Could we please get some clarity on what your plans are?

[BlackStump]

@goeland86 I think @KevinOConnor has made his plans clear here if you are so passionate to move klipper to Python3 then put the development hat on and contribute.

[goeland86]

Thanks for that link. But it was not made publicly available in this thread before.

And I am doing what I can with dev work. I unfortunately have too little time myself during this period.