RFC: Removing support for multiple `python` versions

[HaoZeke]

I'm not sure this ever made sense to begin. For most environment management systems (conda/mamba) except maybe pyenv, support for multiple python versions is very problematic.

error    libmamba Could not solve for environment specs
    The following packages are incompatible
    ├─ python 3.8  is requested and can be installed;
    └─ python 3.9  is not installable because it conflicts with any installable versions previously reported.
critical libmamba Could not solve for environment specs

Would be good to hear thoughts. Examples of this being used in the wild would also be most welcome. I couldn't find any from a naive Github search.

In support of removing this functionality would be that it would be much easier to handle non-standard python versions and remove ambiguities:

• https://github.com/airspeed-velocity/asv/issues/980

• 1117

• https://github.com/airspeed-velocity/asv/issues/1294

[HaoZeke]

cc @fangchenli @datapythonista @mattip , anyone else

[fangchenli]

+1

[trexfeathers]

This is presumably rooted in the same logic as the dependency matrix - the idea of having several benchmarking 'streams' that could then be compared. "This benchmark is slower with NumPy v2; this benchmark is slower with Python v3.12 ...". But that doesn't seem to be a popular use case from everything I have read.

[HaoZeke]

This is presumably rooted in the same logic as the dependency matrix - the idea of having several benchmarking 'streams' that could then be compared. "This benchmark is slower with NumPy v2; this benchmark is slower with Python v3.12 ...". But that doesn't seem to be a popular use case from everything I have read.

Yup, I think though, for asv, and python projects in general, the "language level specification" is much less pronounced than library dependency issues. Compared to C++ or fortran, Python language standards are adapted by libraries fairly quickly, so I'm not sure this is worth supporting here.

Also pythonpath manipulation is very much frowned upon as a practice, the community has pretty much centered on environments defined by one python at a time so it becomes hard to handle.

[jmarcet]

I think comparing performance between different python versions is a very useful feature, specially with the latest performance oriented upgrades in python. With pyenv is quite easy to have all the pythons you want to test available in the PATH so asv can find and use them without further steps.

For instance, it has helped us find out python-3.12 performs quite worse than python-3.11 in our codebase.

[HaoZeke]

I'm going to close this as I am now convinced we do actually need to keep multiple python version support. If there is dissent later we can reopen this.