Drop support for PyPy3 < 7.2.0

[nulano]

Is it time to remove compatibility code for PyPy3<7.2.0 released a year ago on 2019-10-14? See also #4145 (comment).

Changes proposed in this pull request:

• Remove compatibility code in _imagingft.c for PyPy3<7.2.0.

• Pin Travis to pypy3.6-7.3.1. The simple pypy3 is currently pointing to the over-year-and-a-half-old 7.1.1-beta0 version, see https://docs.travis-ci.com/user/languages/python/#pypy-support. This version also needs the setuptools update.

  Travis does not yet support 7.3.2 released two weeks ago, see https://travis-ci.community/t/add-pypy-7-3-2-support/10007.

• PyPy3.6-7.3.2 is now available on GHA and fixes the issue in test_imagefont.test_unicode_extended on Windows. Remove pytest.mark.xfail. This will also be needed for test_cbdt[_mask] tests from Add support for CBDT and COLR fonts #4955.

  I don't remember if this was needed on MacOS with PyPy 7.3.1 or older, but the wheels for the 8.0.0 release (Release Pillow 8.0.0 on October 15, 2020 #4764) should ideally (I'm assuming) target the latest 7.3.2 version.

I did not remove the distutils envars from #4746 (comment) which are no longer necessary as of 7.3.2. I think it makes sense to keep these until Python 3.6 support is dropped at which point users will have to upgrade PyPy anyway (PyPy 7.3.2 is the first to support Python 3.7).

[radarhere]

A year doesn't seem very long when talking in the context of end-of-life. The more interesting thing to me is that PyPy 7.2.0 is the first to support 3.6 without the word 'beta' included as a warning.

I don't remember if this was needed on MacOS with PyPy 7.3.1 or older, but the wheels for the 8.0.0 release (#4764) should ideally (I'm assuming) target the latest 7.3.2 version.

I would have thought the wheels should target the earliest support version, rather than the latest, to ensure compatibility. But the wheels are generated at pillow-wheels, not here, so I don't think that's relevant.

[hugovk]

I asked PyPy on Twitter:

@pypyproject CPython lists supported (3.6-3.9) and EOL versions:

https://devguide.python.org/#status-of-python-branches
https://devguide.python.org/devcycle/#end-of-life-branches

Does PyPy have a similar concept? Or is it just the latest release, i.e. now only PyPy 7.3.2 (for Python 2.7, 3.6, and 3.7) is supported?

https://morepypy.blogspot.com/2020/09/pypy-732-triple-release-python-27-36.html

Their reply:

It's the latter, we only really support the most current release.

---

I suggest in general we aim to support the latest release of PyPy?

(Excluding any Python versions that are EOL by CPython, i.e. Python 2.7.)

And as Pillow 8.0.0 is a major release, it's okay to remove old compat code?

[hugovk]

Please also add to the release notes.

[nulano]

A year doesn't seem very long when talking in the context of end-of-life. The more interesting thing to me is that PyPy 7.2.0 is the first to support 3.6 without the word 'beta' included as a warning.

I seem to recall a comment from PyPy about a similar issue where they mentioned something along the lines of "... you can remove it after a year or so ..." and wanted to link to it later, but I'm having trouble finding it.

I don't remember if this was needed on MacOS with PyPy 7.3.1 or older, but the wheels for the 8.0.0 release (#4764) should ideally (I'm assuming) target the latest 7.3.2 version.

I would have thought the wheels should target the earliest support version, rather than the latest, to ensure compatibility. But the wheels are generated at pillow-wheels, not here, so I don't think that's relevant.

The relevant part is that I'm not sure if the tests can pass on 7.3.1 on MacOS, and that change is made here.

I suggest in general we aim to support the latest release of PyPy?

Makes sense to me. Additionally, 7.1.x is now two major versions behind.