End of py2.7 support

[mdavidsaver]

As announced, after 4.2.2 I no longer see maintaining python < 3.7 support as necessary. So the door is open to dropping support.

Practically, I think "dropping support" would need to include at least:

• Adjust package meta-data
  • python_requires= in setup.py
  • Something in pyproject.toml?
• Remove GHA jobs
• Update documentation/building.rst

It seems best to do this as a separate PR.

And be followed up by some cleanup:

• Remove unicode = str
• Audit sys.version_info tests
• Audit ImportError
• Collapse asynciotest.py into test_asyncio.py
• Audit __del__
• language_level in cython
• from __future__ import print_function
• ... and probably more

[mdavidsaver]

• Something in pyproject.toml?

It appears to me that, with setuptools at least, it is not possible to specify requires-python in pyproject.toml without giving up the ability to dynamically generate install_requires.

... and setup.cfg could work, but it is parsed after starting to execute setup.py.

Happily, this may not matter. setup.py sdist emits a *.egg-info/PKG-INFO containing a Requires-Python: .... This ends up in the pypi.org meta-data.

[mdavidsaver]

@coretl @AlexanderWells-diamond @ralphlange Would numpy >= 1.15 be a reasonable requirement going forward?

numpy 2.2 complains when p4p requests NPY_TARGET_VERSION = NPY_1_15_API_VERSION, so this question may be moot in practice.

The first numpy series to publish py3.8 wheels was 1.17.

[mdavidsaver]

Cython 3 complains about P4P defining the undocumented __PYX_EXTERN_C C macro instead of the new (with cython 3) CYTHON_EXTERN_C macro.

I am inclined to ignore this warning for the time being as it would mean requiring Cython 3, which I suspect will currently pose a problem for some "enterprise" Linux installations.

[ralphlange]

+1 for that (ignoring for a while)

ITER packages its own Cython3, so we're not directly affected, but I can see how things would break on "enterprisy" ("self-inflicted legacy"?) systems.

[AlexanderWells-diamond]

I have no use-case for Python < 3.7 so am happy to drop support. At Diamond we're trying to move towards containerized deployments so the versions supported become less and less important - if we run into troubles we just make a new container to deal with it.

[ralphlange]

How I would love to have that flexibility...

[rosstitmarsh]

As a first pass for the tidying up the code now Python < 3.8 is not supported, could you run a basic pass with a formatter like ruff (and linter with a minimal set of rules like sorting imports) to get started? This will make everything consistent and make contributing gradual type annotations and other improvements simpler.