ttkwidgets
ttkwidgets copied to clipboard
TkinterEP
Dropping python 3.4 and 3.5 support
Python 3.4 has already reached EOL, and 3.5 is due to reach EOL the 13th of september 2020.
Furthermore, on unix systems, the system interpreter uses python 3.7 by default. There is not much of an advantage in keeping backwards compatibility with unsupported versions of python.
I do not mind dropping support for Python 3.4, but dropping support for Python 3.5 is not something that I think is appropriate yet. There is indeed only a little under two months to go at the time I'm writing this, but some platforms have not yet switched to Python 3.6 or a higher version. For example, while I do not depend on ttkwidgets on them, my BeagleBone Black single-board computers are still on 3.5.
However, maybe we should discuss this more as a general thing? Say, we stop investing time in making things work on old Python versions after their official EOL date, or, possibly three months after? I think that should indeed be very reasonable.
Hey, I'm bumping this thread since Python 3.5 has reached EOL as of 3 months ago.
I do think it's reasonable not to spend time supporting older python versions, at least, python versions that have reached EOL (giving it 3 months is reasonable in my opinion).
I think we should target for 3.6.5+ so that we have access to the blessing that are f-strings.
During the holidays I will be spending some time on various projects, particularly gttk, but I don't feel particularly inclined to rewrite existing code to remove Python 3.4 and 3.5 support explicitly. I am more than fine with disabling the tests on those versions though, as indeed Python 3.5 has reached EOL. And I agree, f-strings are great.
Do you agree, or do you actually want to update the existing widgets?
Well, in my opinion, there's no reeason to intentionally break compatibility, but there's no reason to keep supporting these versions of python.
The best course of action is to update the setup.py to require python 3.6+ and drop the tests for previous versions of python. We can update the strings later on to use f-strings instead down the road, because they look much cleaner than the alternative (% strings and .format)