Anybody still using Python2?

[Richard Laager]

Python 2 has been upstream EOL for 5 years. The burden here should be on 
people who want to keep supporting it, not on people who want to drop 
support for it.

On 2025-01-30 18:19, Fred Wright via devel wrote:
> On Wed, 29 Jan 2025, Hal Murray wrote:
>> That makes sense.  But I'm missing the next step.  Do sites still using
>> mostly Python 2 have Python 3 available?  Are they writing new code in
>> Python 2 or 3?
> 
> It's not about new code; it's about existing code that may not work with 
> Python 3.

[reordered for reply flow]
 >> How many people/distros are running python 2 without python 3 being
 >> available and also want to run ntpsec?
 >
 > It's not about whether Python 3 is available, but about whether it's
 > usable for whatever code they may have that uses ntpsec's Python
 > modules.

What "code [do] they...have that uses ntpsec's Python modules"?

I don't think I have seen any third-party code using NTPsec's Python 
modules, only the built-in utilities. In Debian, I only ship a Python 3 
version of the "ntp" module from NTPsec and I've never heard from anyone 
that this was a problem. I realize lack of complaints doesn't prove 
anything, but it's anecdotal evidence at least.

> Also note that Python 3 isn't the only Python version that breaks stuff;

Sure, but that's the issue being discussed: do we drop support for Python 2?

> it's just the most significant.  E.g., if you want a sane interaction 
> between signals and select()/poll(), then you shouldn't use a version 
> later than 3.4, since they intentionally broke it in 3.5.

I don't know about this particular issue, but for the sake of argument, 
I'll take everything you said as given. Did they fix it in some newer 
version? If not (which your answer suggests), then clearly they aren't 
going to. Python 3.5 was a long time ago, released 2015-09-13 with the 
last 3.5.x bug fix being 2020-09-05. As a consumer of the language, at a 
certain point (which in this case is surely past), you have to accept 
the situation and move on (in whatever way) from there. It's not a 
sustainable answer to expect to say on Python 3.4 forever.

>> We have:
>>      --python=PYTHON     python binary to be used [Default:
>> /usr/bin/python]
>> But that doesn't say if it's *with* or *for* so I assume the split 
>> doesn't
>> yet exist.
> 
> That option is for "for".  The "with" is defined by whatever Python 
> version is used to run waf.  The option is intended to allow them to be 
> different, but IIRC it doesn't currently work correctly, at least in 
> some cases.

That option is a straight substitution, IIRC. So it should work (within 
the limit of what that option is intending to do; the whole problem 
space is more complicated than just that option, of course).

But the fact that we aren't _sure_ about this stuff is indicative of the 
sort of hassle that supporting Python 2 is causing.

Plus, if we went to Python 3, we could get rid of all the poly shims, 
which would be a benefit for people understanding the code.

>>> 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?

This is backwards. We should stay current on our dependencies, absent 
some specific reason. And if there is a specific reason, that needs to 
be time limited in some way:

   - We will stay on this old version until we can update our code.
   - We will stay on this old version until they land a fix for bug X.
   - We will stay on this old version until we replace this dependency.

If we fall behind on dependencies, then we eventually get painted into a 
corner. That is not a sustainable position.

>>> Given the
>>> excruciatingly poor state of waf documentation, the "if it ain't broke
>>> don't fix it" philosophy is generally a safer choice.

If we can't trust waf, then we should move to something else. But that's 
a different discussion than what we are having here.

>> Not quite the shiny thing, but close.  There is:
>>  ntpsec doesn't build with waf >= 2.1.0
>>  https://gitlab.com/NTPsec/ntpsec/-/issues/830
>> but that's based on:
>>  If not using the waf script bundled with ntpsec (as might be
>>  required by distro-specific packaging guidelines),
> 
> Ah, I wasn't aware that it ever used an unbundled waf.

<hat type="debian">

As some related context: Debian doesn't (currently) use unbundled waf, 
but we do repack the upstream tarball (per Debian requirements) to use 
the source of waf because:

'waf "binary" is basically a Python script with an embedded bzip2 
tarball unpacked at runtime.'

https://wiki.debian.org/UnpackWaf

And that repacking script has its own Python 2 vs Python 3 issues. In 
the copy of it in the ntpsec package, I wrote:

This version of repack-waf has been modified to call waf using python3. 
If we use python here (explicitly or implicitly) when python is 
python2.7, we end up with a version of waf that raises SyntaxError on 
python3. If we use python3 here, the result runs in both Python 3 and 
Python 2.7.

If there was a reasonable option to use unbundled waf, I would seriously 
consider that for the Debian package, as it would avoid the repacking 
complexity.

</hat>

-- 
Richard