Python 3.7, 3.8, 3.9, or 3.10 as minimal version

[keelung-yang]

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:

• Structural Pattern Matching
• Allow writing union types as X | Y
• Parenthesized context managers

Cons:

• Latest Python version, most Linux distros now support now
• No PyPy3.10 release info available

Python 3.9

---

Pros:

• built-in CAN_RAW_JOIN_FILTERS support
• built-in CAN_J1939 support
• Dictionary Merge & Update Operators
• Supported or built-in in recent released Linux distros
• PEP 585, type hinting generics in standard collections (update)

Cons:

• PyPy3.9 not released, but should be soon, according it's release history.

Python 3.8

---

Pros:

• Assignment expressions
• f-strings support = for self-documenting expressions and debugging
• Positional-only parameters
• Supported or built-in in most Linux distros
• PyPy3.8 released

Cons:

• Not supported or or built-in in old Linux distros

Python 3.7

---

Pros:

• built-in CAN_ISOTP support
• The new breakpoint() function.
• Forced UTF-8 Runtime Mode
• Python data model improvements
• New Time Functions With Nanosecond Resolution
• Best compatibility compared with 3.8~3.10

Cons:

• Some popular packages have dropped support 3.7, such as NumPy, IPython. more packages should also drop 3.7 support in furture.
• No CAN_RAW_JOIN_FILTERS & CAN_J1939 intruduced in 3.9 (best features in CAN bus in personally)
• No assignment & f-string self-documenting expressions intruduced in 3.8 (best features in language in personally)
• All new features in 3.7 are included in 3.8~3.10.

---

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.

[felixdivo]

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+:

• built-in CAN_RAW_JOIN_FILTERS support -> We can still use it, it is very common to check for a platform's capabilities in the code
• built-in CAN_J1939 support -> Is out of scope for this library
• Dictionary Merge & Update Operators -> Nice, but not that essential for us
• Assignment expressions -> We can wait for them for a release, they are not a game changer
• f-strings support = for self-documenting expressions and debugging -> Nice, but the current code works fine without
• Positional-only parameters -> We would probably add deprecation notes for this first (?)

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.

[felixdivo]

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!

[felixdivo]

Related: #1234

[keelung-yang]

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.

[j-c-cook]

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.

[felixdivo]

(I'll retreat from this discussion as I did from the project in general)

[j-c-cook]

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?