Anybody still using Python2?

[Fred Wright]

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).

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

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

Of course they won't, because they consider this misbehavior to be a 
feature.

Though this particular issue wouldn't have come about if the original Unix 
designers had adopted the PCLSR approach (from ITS) to interrupted system 
calls, instead of the lamer approach that they came up with.

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

Maybe not for everyone, but that should be the user's choice.

But that was primarily meant as just one example of how newer isn't always 
better, especially where Python is concerned.

>>> 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).

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

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

That particular issue isn't about Python 2 vs. Python 3 specifically, but 
just about targeting a different Python version than waf is running with. 
It could just as easily apply to 3.x vs. 3.y.

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

Not automatically.  The whole polyXXX mechanism was never intended to be a 
long-term approach to polyglot code; it was a hack that Eric came up with 
to expedite adapting existing Python 2 code to work with Python 3, with a 
minimum of changes.  One can write polyglot code without polyXXX wrappers, 
but one has to avoid the traditional str == bytes assumption.  The polyXXX 
wrappers just provide a way to make the distinction in the references to 
the data rather than the data itself.

Ripping out polyXXX wrappers without fixing the underlying code is far 
more likely to break Python 3 than Python 2.  And doing that *after* 
desupporting Python 2 is clearly asking for trouble.

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.

Fred Wright