What to do in 2020 - Python 2 EOL

[felixdivo]

Being the last of the 2.x series, 2.7 will have an extended period of maintenance. Specifically, 2.7 will receive bugfix support until January 1, 2020. After the last release, 2.7 will receive no support.

It's no secret that Python 2 is reaching its end of life.

What do we do from then on? Should we just document which version was the last to support Python 2 + 3 and then do a (possibly incremental) cleanup of the code and only support Python 3 from then on? We could do that in a major version bump (like maybe 4.0).

I would vote for exactly that. Do we all agree on that?

[felixdivo]

cc @hardbyte @christiansandberg

[hardbyte]

Yeah I'm in favor of making a python-can v3.2 release be the final release supporting python2 (with possible bug fixes accepted to a 3.x up until python 2 EOL), that frees us up to do a major version bump to v4 where we could drop python2 support and possibly introduce type annotations throughout the core.

[felixdivo]

Adding typing sounds great indeed! This works especially well because Python 3.4 will reach EOL 2019-03-16. So we would support Python 3.5+ only, which enables us to freely use the typing module.

But we cannot use the "new" typing syntax yet, since it is only supported by Python 3.6+, which will be supported until 2020-09-13.

[danielhrisca]

Why not jump straight to Python >= 3.6?

[felixdivo]

Why not jump straight to Python >= 3.6?

Because Python 3.5 is supported until 2020-09-13.

[hardbyte]

That doesn't mean we have to support Python3.5 in python-can v4. Any Python3.5 users can always use python-can<=3.2.

I work on another codebase using comment based typing and it is a bit of a pain so I'd prefer to make the jump to the new typing syntax.

[danielhrisca]

I think Python 3.6 brings some compelling features: f-strings, ordered dicts with better performance, annotations, improved asyncio

[felixdivo]

Okay, you two convinced me. The users on "archaic" systems may still stay on 2.3.x 👌

[felixdivo]

This can be closed once #594, #595, #596 and #597 are merged.

We should probably open new issues for

some compelling features: f-strings, ordered dicts with better performance, annotations, improved asyncio

[christiansandberg]

Sorry for reopening this but I felt like the drop of support for Python 3.5 could be discussed a little further before going all in on 3.6+. We should consider that the current Debian stable as well as Raspbian only have 3.5. Corporate environments are also usually slow to adapt new versions unless they need to. That is probably going to leave a major user base out that need bug fixes and new features. It might end up with forks or maintenance branches. Are the nice-to-have features like f-strings and new variable typing (what else?) really so important that it makes it worth it?

[felixdivo]

Huh, maybe we should've discussed that earlier. But I agree that dropping it now might exclude some users. But (at least for my needs) python-can 3.2.0 was already "good enough" in terms of bugs and supports all these CPython versions. I'm okay with dropping the support. I'm also fine if we agree on still supporting Python 3.5 but it will slow down typing adoption further and I personally do not want to dig & undo the (probably only few) recent 3.6-only changes.

[christiansandberg]

We are more on the bleeding edge side of things compared to the average Python user. Most users are probably not aware of the new features and are fine with using whichever version is provided to them.

A few bugs have already been fixed since we dropped the support and no software is bug-free and feature complete for everyone. There is a risk that fixes and features are not shared back if you can't use develop.

I guess it all depends on when 4.0 will get released. Django is also dropping support for 3.5 but that will not be released until December 2019 which seems like a good time frame for something like this.

I see just a few f-strings here and there so I can certainly fix that quickly.

[felixdivo]

Suppose we support it in 4.0, which we would release in, say December. Then there will only be 9 months of supported usage of the library. Is that really worth it?

[christiansandberg]

Seems like a very long time to wait for December to release anything.

[christiansandberg]

Maybe we could check the python version in the top level module and raise a more descriptive exception about supported versions. Otherwise we’re going to have a flood of SyntaxError issues.

[felixdivo]

That sounds good!

[felixdivo]

I this really still relevant?

[hardbyte]

I don't think we need to check the Python version in our library. Our setup.py/pyproject.toml should specify the minimum right?

See https://packaging.python.org/guides/dropping-older-python-versions/#dropping-a-python-release

Lets close this once we have a 4.x prerelease that drops Python 2 support up on pypi.

[felixdivo]

This is somewhat the case: https://pypi.org/project/python-can/4.0.0.dev0/

[hardbyte]

Quiet right, closing.

[keelung-yang]

Sorry for reopening this but I felt like the drop of support for Python 3.5 could be discussed a little further before going all in on 3.6+. We should consider that the current Debian stable as well as Raspbian only have 3.5. Corporate environments are also usually slow to adapt new versions unless they need to. That is probably going to leave a major user base out that need bug fixes and new features. It might end up with forks or maintenance branches. Are the nice-to-have features like f-strings and new variable typing (what else?) really so important that it makes it worth it?

@christiansandberg, @hardbyte
This issue is opened in 2019 and closed in 2020. And now it's 2022. So it should be reopened again before releasing v4.0?

Python-can supports PyPy. So what's about following python3 versions in PyPy?

Seems Python 3.8 is better than 3.6:

• Debian 11 released with Python 3.9
• PyPy supports Python 3.8 now
• Ubuntu 20.04 includes Python 3.8
• In Ubuntu 18.04, you can install Python 3.8 by apt without additional requirements.

[danielhrisca]

FYI: numpy also dropped Python 3.7 support

[felixdivo]

Dropping 3.6 seems reasonable since it has reached end-of-life.

I don't see the point of dropping support for 3.7 if there isn't a good feature for which we require 3.8+.

[keelung-yang]

FYI: numpy also dropped Python 3.7 support

Same as in IPython: Minimal Python is now 3.8

I don't see the point of dropping support for 3.7 if there isn't a good feature for which we require 3.8+.

There are two features added in Python 3.9:

• The socket module now exports the CAN_RAW_JOIN_FILTERS constant on Linux 4.1 and greater
• The socket module now supports the CAN_J1939 protocol on platforms that support it

So Python 3.9 is better then 3.8 if only considering CAN bus improvements.
But PyPy3.9 is not released now.
I can't found PyPy release schedule, but according to date of releasing 3.6~3.8, PyPy3.9 should be released soon.

• pypy3.8-v7.3.6-aarch64.tar.bz2 2021-10-17
• pypy3.7-v7.3.5-aarch64.tar.bz2 2021-05-23
• pypy3.6-v7.0.0-linux64.tar.bz2 2019-02-06

https://downloads.python.org/pypy/

[felixdivo]

If you think that we should drop support for more than 3.6, we should probably open a new issue. This topic ("What to do in 2020 - Python 2 EOL") is over. 😃