Anybody still using Python2?

[Fred Wright]

On Wed, 29 Jan 2025, Gary E. Miller via devel wrote:
> On Tue, 28 Jan 2025 20:05:11 -0800
> Hal Murray via devel <devel at ntpsec.org> wrote:
>
>> Gary said:
>>> And yet, we still get complaints.  There are maintained Python 2.7
>>> forks that some distros still use and update.
>>
>> I've seen at least one distro that had python 3 but python still went
>> to python 2.  I assume they had a lot of code that still needed
>> python 2.
>>
>> For setups like that, we should be able tell our code to use python 3.
>
> Yes, which still leaves the folks with only Python 2.7.xx in the cold.

It's not about "with" in the sense of what's on the system; it's about 
what Python version *their code* works with.  Due to the large 
incompatibilities between Python 2 and Python 3, it takes serious work to 
update existing Python 2 code to work with Python 3.  And such fixes often 
impact code paths which are rarely used and poorly tested, leading to 
long-lurking bugs associated with such updates.  For example, SCons was 
still fixing bugs related to Python 3 long after it dropped support for 
Python 2 (making the "just run it with Python 2" workaround impossible).

If this were just about using Python for internal purposes, then it would 
be just a matter of supporting at least one Python version available on 
any platform of interest.  But ntpsec provides Python code for *users* to 
use with it, and needs to support whatever version *users* want or need to 
use, including Python2 code that hasn't been updated to work with Python 
3.  Even if a distro comes without Python 2, it's a near certainty that 
Python 2 is available as a package, so distro contents is a poor 
criterion.

Note that the version of Python that ntpsec builds *with* isn't 
necessarily the same as the version it builds *for*, though I suspect that 
there are bugs in mismatching them.  The main problem is that any aspect 
of the build procedure which needs to know some property of Python needs 
to launch the target Python and query it, rather than just querying the 
Python running waf.  GPSD has been doing this for a long time, which is 
why it can still build *for* Python 2.7 while being forced by recent SCons 
versions to build *with* Python 3.

Is there some specific reason to want to move to a newer waf, or is it 
just a case of wanting the latest shiny new thing?  Given the 
excruciatingly poor state of waf documentation, the "if it ain't broke 
don't fix it" philosophy is generally a safer choice.

>> Another possibility would be to ship a release that still supports
>> 2.6, but with a big warning.  Then we can ship another release
>> quickly after that which drops support for python 2.

It's important not to conflate dropping 2.6 with dropping 2.*.

> I have heard no one in a long time that wants 2.6

I've previously objected to dropping 2.6, just because the reason for 
doing so was really lame (literally, just saving five characters in a set 
initializer).  If there's a *good* reason to drop 2.6, then so be it.  But 
drop 2.7 at your peril.

The reason for not supporting anything earlier than 2.6 is that some 
features to facilitate making code work with both 2.x and 3.x didn't 
appear until 2.6, so that (except in very limited cases) writing code that 
works in both <2.6 and 3.x gets fairly ugly.

Fred Wright