Open keelung-yang opened 2 years ago
First of all, thank you @keelung-yang for your overview!
However, I still hold the position that dropping 3.7 or even 3.8 would not help the library significantly. In general, I'm totally for dropping support for old platforms/tools/... as soon as they reach EOL or newer versions offer great new features. That was certainly the case for 3.6 which added f-strings and syntax for variable annotations, which greatly helped with maintainability! However, I don't see much benefit from dropping support for a platform that we supported until a week before a huge release. The features we would get by going 3.9+:
I am aware that this is my subjective opinion. I would feel different about this if there would have been a release earlier in the support of the "old" Python versions 3.7-3.8. Once we have 4.0.0 (and maybe a first maintenance release) out, we can still think about using the features you list above.
I propose continuing the discussion once 4.0.0 is out. @keelung-yang you are right in that we should discuss this, so we should leave this open!
Related: #1234
Here are Python life cycles from https://endoflife.date/python
Update1: As described in above link,
Python 3.9+ cannot be used on Microsoft Windows 7 or earlier versions. Last Windows 7 installable version is python 3.8 series
And Python 3.7 ends in 1 year and 3 months. So Python 3.8 seems a appropriate minimal version in next release.
Update2: PEP 585, type hinting generics in standard collections
is great but introduced in Python 3.9.
From now on there are 49 lines of from typing import ...
found by grep -nr "from typing"
. They're not necessary if using Python 3.9 and convenient for type hinting.
Does this repository follow semantic versioning? It seems to me that changing the minimum functioning Python version is akin to an API deprecation. API deprecation should only occur on major releases. This may be the kind of thing that an issue should be opened and named "Planned deprecations for v5.0" see example here. Perhaps this should be moved to a "v5.0" milestone?
I understand that NumPy changed their minimum Python version on release v1.22.0
. Had I been involved in those discussions, I would have pushed for a major release when dropping support for Python 3.7. Changing minimum Python versions is no joke, which is exactly why we may never have a Python 4.x. Python 3.7 is supported until June 27, 2023. I propose that a minimal Python version for the next major release be chosen by then (either 3.8 or 3.9).
I have commented on @keelung-yang's original post about the cons of continuing support for Python 3.7 in the next minor release of v4 below:
Cons:
* Some popular packages have dropped support 3.7, such as NumPy, IPython. more packages should also drop 3.7 support in furture.
This package is not dependent on NumPy. Thankfully, the dependencies are minimal. This becomes extremely relevant when trying to run this package on an obscure chip architecture that does not have a pre-built Python installation or associated Conda distribution. Flexibility for the user is not a con.
* No CAN_RAW_JOIN_FILTERS & CAN_J1939 intruduced in 3.9 (best features in CAN bus in personally)
This may be a reason to bump from 3.7 to 3.9 and skip 3.8 entirely, but at the next major release.
* No assignment & f-string self-documenting expressions intruduced in 3.8 (best features in language in personally)
Yes, we cannot use the walrus :=
operator for the time being because the Python 3.7 API does not support it. Which is exactly why it makes sense to be discussing this subject for a major release, not a minor one. Changing the minimum Python version may not be directly modifying our API, but usage of the new features in 3.8 will break when executed from Python 3.7.
* All new features in 3.7 are included in 3.8~3.10.
This is not a con. This is defining what it means to support Python 3.7.
(I'll retreat from this discussion as I did from the project in general)
I understand that an argument could be made that Python 3.7 to 3.8 is a minor release, so in the next minor release it should be sufficient to change the minimum available Python version. However, I'm not sure what python-can
gains as a package by changing the minimal version from 3.7 to 3.8. It could potentially introduce more work for the users, and for what reason?
@hardbyte Is this also a discussion?
Hi, This is continued discussion of Python3 at the end of #528 which is about Python2. I summary pros and cons dicussed in #528 and important features in official What's new in Python 3.X
Python 3.10
Pros:
Cons:
Python 3.9
Pros:
Cons:
Python 3.8
Pros:
Cons:
Python 3.7
Pros:
Cons:
Also, asyncio module is almost improved in each main version of Python.
So, in personlly, I prefer Python 3.9 or 3.8 as minimal supported version.