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@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
_______________________________________________
devel mailing list
devel@ntpsec.org
https://lists.ntpsec.org/mailman/listinfo/devel
