Drop support for early python 3.5.x point releases?

[njsmith]

We have another issue about when to drop support for 3.5 entirely (#75). This issue is to discuss something narrower: should we drop support for some early 3.5.x releases, while keeping it for later ones?

Possible advantages:

• The semantics of __aiter__ are totally different in 3.5.0 and 3.5.1 versus 3.5.2. We have to carry around special hacks to support those old versions.

  • The hacks themselves are not too terrible to maintain. The biggest issue is that they add more entries to the test matrix, which is extra complexity and getting gradually more difficult (e.g. on Travis we have to fall back to the older trusty environment to get access to an old enough Python, and Azure doesn't provide any old 3.5.x's at all.)

• The typing module also went through a lot of changes over the lifespan of 3.5.x. I haven't looked into the details here, but @oremanj says "it looks like 3.5.2 was the first version with a typing module that's even kinda usable for async code". I guess as soon as we start seriously tackling Provide PEP 484-style type hints #543 we'll quickly discover the limits!

Possible disadvantages:

• It's easier to explain "we support 3.5 or greater" than to explain "we support 3.5 or greater, except for these micro-versions of 3.5, by the way do you even know what micro-version of 3.5 you're using?"

Who would be affected?

• pypy's 3.5 branch claims to emulate 3.5.3. (And I guess we could convince them to bump that higher if necessary? they also have a 3.6 branch that's in pretty solid shape, but who knows when that will actually release.) pypy's on 3.6 now

• Debian stable has 3.5.3 now oldstable has 3.5.3, and stable has 3.7.something.

• Ubuntu 14.04 "trusty" defaults to 3.4, but has 3.5.2

• Ubuntu 16.04 "xenial" has its default python3 as 3.5.2

• Ubuntu 18.04 "bionic" defaults to 3.6.7

• On Redhat/CentOS 6 and 7, AFAICT there's no python 3 in the main distro (is this true?), so people use EPEL or Software collections or whatever. EPEL 7 has python 3.4 and python 3.6, no 3.5 at all. EPEL 6 doesn't have anything newer than 3.4. Software collections has a variety of versions, including both 3.5 and 3.6. Their 3.5 is 3.5.1. (See the rh-python35-python-3.5.1-11.el6.x86_64.rpm package on this list, and I also installed it in a container to check.)

So it sounds like pretty much everyone who has an officially supported 3.5.anything, has an officially supported 3.5.2+, except that if anyone is using software collections then getting 3.5.2+ requires upgrading to 3.6.

Another source of stats is PyPI downloads: https://pypistats.org/packages/trio. The numbers are pretty noisy because we don't have a lot of downloads, and for these purposes I'm much more worried about people trying to run their first program than heavy users, so the download stats may not be super representative anyway. But it looks like right now our downloads are ~5-10% python 3.5, and most of the rest on newer versions.

[oremanj]

It turns out that all the missing typing features I care about seem to be in typing_extensions (a PyPI package), so I feel less strongly about this than I did previously.

[oremanj]

A lot of typing bugs were fixed in 3.5.2, though. I just ran into this one on #908:

from typing import Generic, TypeVar
T = TypeVar("T")

class X(Generic[T]):
  __slots__ = ("a",)

X()  # ok
X[int]()  # fails

class Y(X[int]):  # fails
  __slots__ = ()  # regardless of whether Y is slotted or not

The issue doesn't occur if the generic class is slotted without defining any slots, so the ABCs I hit in #908 are fine, but working around issues like this makes typing less appealing.

[oremanj]

Also, FWIW, mypy itself requires 3.5.2 at minimum.

[WindSoilder]

In early days, I found that python3.5.0 don't provide typing.Type class, it can be useful for the python-trio/exceptiongroup#7
And the CI failure about it lays here:
https://travis-ci.com/python-trio/exceptiongroup/jobs/172449801

[oremanj]

We dropped 3.5 support so this question has become moot!