remove support for Python 2.7, 3.5, 3.6 about polytope

[johnyf]

As of commit 9ee3f96, support for Python 2.7 has been removed, and also support for Python 3.5 and 3.6 has been removed. For motivation, please read the commit messages on branch dev.

[slivingston]

I strongly support this. I think that it can be done without much more discussion. Actually the same for Tulip. I am now a "member of industry" and I can confirm that Python 2.7 is not for new development and mostly survives only where it is deeply embedded in a product, etc.

As for versions of Python 3, I agree with following NumPy. If users have difficulties because of requirements of 3.6, we can discuss or patch as needed. To be explicit, 3.5 is past end-of-life, but 3.6 is scheduled to continue to receive security updates until end of this year.

[slivingston]

Is there any reason not to make the same changes in https://github.com/tulip-control/tulip-control/ ?

[murrayrm]

I think it would be fine to move to 3.7+ for tulip-control.

[johnyf]

Thank you for the comments, I merged the changes from branch dev to the mainline branch of polytope (a23ddcf), so now the supported Python versions have been updated.

I do not know of any reason why to not make the same changes to tulip.

A relevant change is to pass the parameter python_requires to the function setup.setuptools in order to ensure that newer versions of tulip will not be unknowingly installed on unsupported Python versions (this check can be explicitly deactivated with pip install --ignore-requires-python).

This defines the metadata field Requires-Python that is specified in PEP 345. It appears that PEP 503 specifies that when this field is present and communicated by PyPI, then installer tools like pip should ignore the download when running on a Python version that is unsupported by the package.

For python_requires to work effectively, the users need to have pip >= 9.0.0 and setuptools >= 24.3.0 (setuptools >= 24.2.1 seems sufficient too). In any case, python_requires is one of the most dependable approaches for ensuring this.

Including Requires-Python metadata will result in "Requires: Python >=3.7" being displayed in the package's page on PyPI, in addition to the Trove classifiers that declare supported Python versions.

Relevant resources:

• https://packaging.python.org/guides/dropping-older-python-versions/
• https://python3statement.org/practicalities/
• https://packaging.python.org/guides/distributing-packages-using-setuptools/#python-requires

The documentation at:
https://packaging.python.org/guides/distributing-packages-using-setuptools/#classifiers
reads:

Although the list of classifiers is often used to declare what Python
versions a project supports, this information is only used for searching &
browsing projects on PyPI, not for installing projects. To actually
restrict what Python versions a project can be installed on,
use the python_requires argument.

Also, I removed the Python 2 Trove classifiers, but did not add the classifier "Programming Language :: Python :: 3 :: Only", because I am not sure what the convention is, because Requires-Python will have the intended effect independently of what Trove classifiers are used, and also because polytope remains almost compatible with Python 2.7 (the only reason why parts of polytope would now not work on Python 2.7 is numpy version).

Regarding Python 3.10 support, I created a branch py310 that replaces nose with pytest (except inside the script run_tests.py, which needs more studying), adds Python 3.10-dev to the CI test environments ("DRAFT" commit), and declares support for Python 3.10 in the Trove classifiers. The environment setup for Python 3.10 failed on that branch because Python 3.10 has not yet been released, so there does not exist a numpy version on PyPI for Python 3.10.

[johnyf]

I have now changed tulip to require Python >= 3.7. For reasons orthogonal to this Python version requirement, updates were needed to the CI testing configuration. These are mostly completed, and described at: tulip-control/tulip-control#246.

So this issue appears to have been addressed.

Regarding CI testing with Python 3.10 (mentioned above: #70 (comment)), this can be revisited after Python 3.10 has been released and wheels for numpy and scipy for Python 3.10 become available on PyPI. (The CI error was because only binaries are downloaded for numpy and scipy using pip (to avoid CI timeouts and speedup the test runs):

polytope/.travis.yml

Line 22 in a23ddcf

- pip install -U --only-binary=numpy,scipy numpy scipy

so pip cannot find such wheels for Python 3.10. I tried building them locally, and on Python 3.10 building scipy from source distributions available from PyPI did not succeed.)

[johnyf]

This issue has been addressed as of commit beadd12.

About the branch py310 (#70 (comment)), which adds Trove classifiers and CI testing for Python 3.10, I tried locally to override the Python version used by pip when searching for wheel files to download:

pip install -U --only-binary=":all:" --python-version="3.9" --target=/tmp/foo numpy scipy

(The arguments --only-binary=":all:" and --target were required by pip; otherwise pip exited with a message that certain additional arguments need to be given.)

Installation did complete without errors in Python 3.10, but when I cd /tmp/foo and try python -c "import numpy", I get an error that starts with:

> python -c "import numpy"
Traceback (most recent call last):
  File "/.../foo/numpy/core/__init__.py", line 22, in <module>
    from . import multiarray
  File "/.../foo/numpy/core/multiarray.py", line 12, in <module>
    from . import overrides
  File "/.../foo/numpy/core/overrides.py", line 7, in <module>
    from numpy.core._multiarray_umath import (
ModuleNotFoundError: No module named 'numpy.core._multiarray_umath'

The module that was not found is an extension module, namely numpy/core/_multiarray_umath.cpython-39-darwin.so. I opened #71 for tracking support for Python 3.10 (mainly CI testing on Python 3.10).