Drop support for EOL Python 3.5

[hugovk]

Python 3.5 reaches EOL on 2020-09-13:

• https://devguide.python.org/#status-of-python-branches

The next Pillow release 8.0.0 release is due out after that, on 2020-10-15 (#4764).

This removes testing for Python 3.5 on the CIs, updates docs and metadata. I'll send another PR later with syntax updates, but first it's good to reduce the CI usage to speed up PR builds.

Edit: It also removes some redundant PyPy compatibility code for old and unsupported PyPy versions.

---

Notes:

• AppVeyor tests on two Python versions, the lowest supported (was 3.5, now 3.6) and the highest.

• Travis CI and GitHub Actions tested PYTHONOPTIMIZE=2 on the 3.5 job (and PYTHONOPTIMIZE=1 on 3.6). Now it tests PYTHONOPTIMIZE=2 on the 3.7 job.

• Travis CI tested s390x on 3.5 (chosen arbitrarily). Now tests s390x on 3.8, as arm64 is in 3.6 and ppc64le is on 3.7.

[hugovk]

Not relevant for this particular PR, but two of the Docker images are using Python 3.5:

• Debian 9 Stretch (example)
• Ubuntu 16.04 Xenial (example)

I think we can can probably drop the Docker image for Xenial, we test Xenial extensively on Travis CI. (And Xenial's EOL is in April 2021, not too far off.)

As for Stretch (EOL 2022), should we upgrade Python in the image? Have we done that before, or is the idea that the Docker images test the native Python only, and we can drop it?

[nulano]

There are also comments in winbuild readmes winbuild/readme.md:

Python 3.6+ is required to generate valid scripts, but builds targeting Python 3.5+ are supported.

and docs winbuild/docs.rst:

While the scripts can target any version of Python supported by Pillow, Python 3.6+ is required to generate valid build scripts.

[hugovk]

Thanks, updated.

[nulano]

Not relevant for this particular PR, but two of the Docker images are using Python 3.5:

• Debian 9 Stretch (example)
• Ubuntu 16.04 Xenial (example)

These are the only two test jobs running FreeType 2.6.x. Xenial on Travis also has 2.6.1. It would be good to keep at least one of these after Xenial is EOL to make sure FreeType tests have proper metrics for this version.

Amazon 1 and CentOS 6 run FreeType 2.3.1, and all other jobs run 2.8.x or newer.

[jdufresne]

Using Python 3.6+ would allow the project to use f-strings if it is desired. IMO, f-strings tend to be nicer to read than .format() and timeit shows that they are slightly more performant.

pyupgrade can be used to adapt simple cases to use f-string. It only changes instances where the expression is shorter and does not introduce nested quotes. If you're interested, the command is

$ find . -name \*.py -exec pyupgrade --py36-plus {} \;

[hugovk]

Yep, was planning on doing that in a follow up. Wanted to get this smaller one in first to make it easier to review and reduce the CI sooner. Thanks!

[hugovk]

@radarhere Is this okay to merge?

[nulano]

Just to note here so I don't forget:

MSSdk and py_vcruntime_redist will no longer be required by PyPy in the next release.

py_vcruntime_redist is still required by CPython 3.6, but not CPython 3.7.

[hugovk]

Not relevant for this particular PR, but two of the Docker images are using Python 3.5:

• Debian 9 Stretch (example)
• Ubuntu 16.04 Xenial (example)

These are the only two test jobs running FreeType 2.6.x. Xenial on Travis also has 2.6.1. It would be good to keep at least one of these after Xenial is EOL to make sure FreeType tests have proper metrics for this version.

Amazon 1 and CentOS 6 run FreeType 2.3.1, and all other jobs run 2.8.x or newer.

Let's drop these two for now, and can consider either upgrading one from Python 3.5 to something newer, or install FreeType 2.6.1 on another CI job.

More generally, we could pick a minimum version of FreeType to support. Some release dates [1] [2]:

• 2020-05-09: 2.10.2 (newest)
• 2017-05-13: 2.8.0
• 2015-10-04: 2.6.1
• 2007-01-31: 2.3.1