Dropping python 3.5 support?

[njsmith]

Advantages of going to 3.6+:

• f strings
• the __aiter__ mess goes away
• native async generators → slightly nicer tracebacks
• idempotent call_soon becomes guaranteed FIFO (not sure anyone cares but hey)

Disadvantages:

• 3.6 final won't be in any ubuntu release until 17.04
• there's no pypy 3.6 (but pypy 3.5 does have f-string support at least)
• some complications on RTD

My feeling is that it's not quite time to drop 3.5 support, but it wouldn't be too bad to start allowing f-strings in the medium term. And beyond that pypy becomes the gating factor.

[dimaqq]

Odd opinion -- I live in 3.6 only world since b2.
wrt. distro -- that's where pyenv comes in :) or docker
pypy is a bummer, but then again I don't see many projects start with pypy.

What are the options?

• maintain 2 branches
• 1 branch, "dumb" code only
• recommend 3.6 (examples, etc.) just be careful to allow 3.5

[njsmith]

We're definitely not going to maintain 2 branches :-). It's more about when the benefits outweigh the costs. The benefits are currently pretty minor, and as a practical-oriented project we want to avoid creating annoyances for users when possible (and "can't run on ubuntu without weird setup" is definitely an annoyance in these days when so many people run ubuntu servers).

[Victor-Savu]

Personally, I don't even use the distro-provided python: pyenv ftw!

[njsmith]

Well, here's a legitimate argument in favor of dropping support for CPython 3.5: the MacOS releases use an ancient openssl that's making it difficult to properly test our ssl support (pyca/pyopenssl#624)

[joernheissler]

we want to avoid creating annoyances for users when possible (and "can't run on ubuntu without weird setup" is definitely an annoyance in these days when so many people run ubuntu servers).

Current Ubuntu LTS ships cpython 3.6.6
But I use Debian on several of my systems and it won't be before end of 2019 that I can move them to Debian Buster which will have cpython 3.7 (or 3.8?)

Of course I could use pyenv, but I prefer to use the system's python installation.

Next CentOS/RHEL (probably released beginning of 2019) will have cpython 3.6.6 from what I can see.

In my opinion, a good date to drop python 3.5 support would be some time after next debian release, i.e. mid/end 2019.

[smurfix]

I'd like to second @joernheissler's "after the next debian release" proposal.

[njsmith]

Another problem that would go away if we dropped 3.5 support: #1320 (comment)

[auvipy]

good time to drop python 3.5

[pquentin]

Another one is #1306 (but this is only about 3.5.0). But then it's easy to fix.

Looks like Debian stable has 3.7 and Ubuntu 18.04 LTS has 3.6 so we're good there. I don't know what RHEL supports but we probably don't have users there anyway.

According to https://pypistats.org/packages/trio, ~10% of the downloads are Python 3.5 compared to ~20% before 2019-08. But it's quite noisy and it's hard to draw conclusions from those numbers.

But then its end-of-life is 2020-09-13.

[auvipy]

RedHat 8 has python 3.6 https://developers.redhat.com/blog/2018/11/14/python-in-rhel-8/

[joernheissler]

Ubuntu 18.04 LTS has 3.7.3, it's just not an alias for the python3 package.

pypy is at 3.6.9.

RHEL 8 might add newer releases through EPEL some time in the future. But no idea when/if this will happen. RHEL 7 already supports py3.6 through EPEL.

I.e. users that use a "stable" version of the major distros are at least on py3.6

[pquentin]

Another reason for dropping support for Python 3.5 is that it forces us to use Ubuntu 14.04 on Travis and it's currently broken on travis-ci.com (but works fine on travis-ci.org).

[njsmith]

The latest release Trio (v0.14.0) has deprecated support for Python 3.5, and will issue a warning at import time.