Anybody still using Python2?

[Richard Laager]

On 2025-02-01 16:33, Fred Wright via devel wrote:
> On Fri, 31 Jan 2025, Richard Laager via devel wrote:
> 
>> 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.
> 
> The burden shouldn't be on people to keep adapting to new brokenness, 
> rather than using what already works, or newer versions from people who 
> actually think that breaking things is a bad idea (unlike the python.org 
> folks).

If you don't like a dependency, or don't trust the authors of it, then 
use something else.

>> On 2025-01-30 18:19, Fred Wright via devel wrote:
>>> 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.
> 
> You're assuming that all Python code on the planet is published.  I 
> personally have a bunch of unpublished Python code which I've never 
> reworked to work with Python 3.  I don't write any *new* Python code 
> that doesn't work with Python 3, but fixing existing code is real work.

I'm suggesting (and asking for counterexamples) that there is no 
third-party code that uses NTPsec's "ntp" module with Python 2. There is 
quite possibly no third-party code using that module at all.

I'm certainly not assuming that all code is published. There could be 
private code out there. But has anyone seen or heard of any? (I'm asking 
about code that uses the NTPsec Python library; obviously I know people 
have private Python code.)


NTPsec 0.9.0 ("Initial NTPsec beta release") was 2015-11-16. According 
to the git history of pylib/__init__.py, the "installable Python 
libraries" came about on 2016-08-11.

The Python 2 EOL was originally, in 2008, announced to be 2015. However, 
in 2014, it was extended to 2020: 
https://www.python.org/doc/sunset-python-2/

So, for this to be an issue for _third-party_ code, all of the following 
have to be true:

0. There is third-party code using NTPsec's Python library at all.

1. In late 2016 or later, knowing that Python 2's EOL was 2020 (albeit 
also knowing it was extended once), someone wrote third-party Python 2 
code that used NTPsec's Python library.

2. Now, in 2025, they still have not upgraded to Python 3, despite 
Python 2 being EOL for 5 years.

3. They want to run the latest NTPsec code.

4. They can't or really don't want to upgrade to Python 3 now even if 
forced by NTPsec dropping Python 2 support.

For #0, I'm not even sure what the actual uses cases would be. A 
monitoring script that talks directly to the daemon rather than shelling 
out to ntpq, maybe?

#1 seems like a toss-up at best (vs Python 3) as why would someone write 
a brand new thing in Python 2 in 2016? But it's not impossible: maybe 
they didn't have Python 3 on their system, due to it being an older 
distro version.

But in the intervening years, they would have Python 3, so why not 
upgrade the code? The NTPsec Python library is pretty small. I can't 
imagine how the NTPsec Python library would be used in some massive 
codebase where the 2 -> 3 upgrade is difficult. It's probably something 
trivial, e.g. a Nagios monitoring script.

If they aren't upgrading their Python, why are they so concerned about 
running the latest NTPsec code? In other words, if I just have an 
ancient system that's sitting there running and I don't want to touch 
it, this isn't an issue because I'm probably also not upgrading NTPsec.


As an aside... I'm certainly familiar with the complexities of upgrading 
a large, legacy codebase. At $DAYJOB, we had a Django monolith using an 
outdated and custom-patched Django, with a codebase that fought against 
one or two specific Django conventions, that used Python 2. We couldn't 
just upgrade to Python 3, as the old Django wouldn't work there. We 
couldn't just upgrade Django, because we had all this custom stuff. We 
had to carefully untangle all of that, which took a while. But that was 
our fault, for making unsustainable choices. (Note that our choices had 
already prevented us from upgrading Django itself, even staying on 
Python 2.) We adjusted our approach with the upgrade and future upgrades 
of our dependencies, mainly Django, have ranged from trivial to a few 
days' work.


To be clear, I am talking about NTPsec only here. Other projects might 
make a different calculus. For example:

On 2025-02-01 15:26, Gary E. Miller via devel wrote:
 > I'm happy with Python 3, but every time gpsd breaks Python 2.7, I get
 > complaints.  Maybe this year is the last year to deal with this mess.

It wouldn't surprise me at all to find that people have written Python 2 
code to talk to gpsd. And clearly, Gary is saying that's the case. 
First, gpsd is surely more popular than NTPsec. Second, it has been 
around longer, so there could more easily be existing code. Third, it 
seems far more likely that there are use cases for third-party code to 
interact with gpsd than with NTPsec.

>> It's not a 
>> sustainable answer to expect to say on Python 3.4 forever.
> 
> Maybe not for everyone, but that should be the user's choice.

That doesn't obligate us to continue to support it.

One of the major things that NTPsec did when forking from NTP Classic 
was drop all the old cruft. It's baffling to me that we are still having 
this conversation here of all places.

>>>>      --python=PYTHON     python binary to be used [Default:
>>>> /usr/bin/python]

>> That option is a straight substitution, IIRC.

> It's not just a straight substitution, for the reason I previously posted.

I'm sorry, that was my mistake. I was thinking of --pyshebang.

> Removing polyXXX wrappers properly requires actually thinking about the 
> underlying code, a can that was kicked down the road by using the 
> wrappers in the first place.

Agreed.

-- 
Richard