<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<div class="moz-cite-prefix">On 2023-09-04 17:38, James Browning via
devel wrote:<br>
</div>
<blockquote type="cite"
cite="mid:8076ed2b-71ba-4c05-a1f6-06ca50a03be8@email.android.com">
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
<div dir="auto">
<div>
<div class="gmail_extra">
<div class="gmail_quote">On Sep 4, 2023 14:46, Matthew
Selsky via devel <a class="moz-txt-link-rfc2396E" href="mailto:devel@ntpsec.org"><devel@ntpsec.org></a> wrote:<br
type="attribution">
<blockquote class="quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<p dir="ltr">On Mon, Sep 04, 2023 at 02:25:46PM -0700,
Gary E. Miller via devel wrote:
<br>
<br>
> From RHEL:
<br>
> <br>
> "The RHEL 8 AppStream Lifecycle Page puts the end
date of RHEL 8's
<br>
> Python 2.7 package at June 2024."
<br>
> <br>
> <a class="moz-txt-link-freetext" href="https://access.redhat.com/solutions/4455511">https://access.redhat.com/solutions/4455511</a>
<br>
<br>
Hi Gary,
<br>
<br>
Is the implication that we can safely drop python2
support after June 2024? Are there any other
distributions that ship python2 that we want to
maintain support for?
<br>
<br>
How much does it cost us to maintain python2 support
in our own code?<br>
</p>
</blockquote>
</div>
</div>
</div>
<div dir="auto">By dropping 2.6 support we would eliminate the
need to check for argparse in a few place, glue to replace
ordereddict?, be able to use with for resource allocatoion,
and the need to pretend to test on 2.6. </div>
<div dir="auto">
<div class="gmail_extra">
<div class="gmail_quote">
<blockquote class="quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<p dir="ltr">
</p>
</blockquote>
</div>
By dropping 2.7 we could probably assume secrets which
simplifies ntpkeygen, simplify ntp.poly, be able to drop the
now oldoldstable? runner testing for asciidoc on python 2
support, and also have the option of adding type hinting.</div>
</div>
</div>
</blockquote>
<p>Dropping support for Python 2 should allow for dropping most of
the poly infrastructure. That code (pylib/poly.py) involves some
contortions (see also [1]) to make it possible to run on both
Python 2 and Python 3. The downside is that it is most definitely
not Python 3 idiomatic. In fact, it's closer to Python 2 than
Python 3. If you look at the code, you'll see that there's very
little that happens in the Python 2 case and a lot more that
happens in the Python 3 case. This was (presumably) a good
trade-off when trying to minimize the work for an existing
codebase to gain Python 3 support without dropping Python 2
support. But it does leave technical debt to be cleaned up when
going full Python 3.<br>
</p>
<p>If we dropped support for Python 2, that should come in a couple
phases. Phase 1 would be removing anything relating to Python 2
itself. It should probably also include any changes relating to
Python detection with waf. Phase 2 would be <i>carefully</i>
removing usage of the poly infrastructure, converting to idiomatic
Python 3 approaches. Once that is done, then we'd be rid of the 2
-> 3 conversion baggage. These phases need not be separate
releases, but should (IMHO) certainly be separate commits and
likely be separate PRs.<br>
</p>
<p>[1] <a class="moz-txt-link-freetext" href="http://www.catb.org/esr/faqs/practical-python-porting/">http://www.catb.org/esr/faqs/practical-python-porting/</a><br>
</p>
<pre class="moz-signature" cols="72">--
Richard</pre>
</body>
</html>