Is python2 dead?
rlaager at wiktel.com
Tue Sep 5 00:24:22 UTC 2023
On 2023-09-04 17:38, James Browning via devel wrote:
> On Sep 4, 2023 14:46, Matthew Selsky via devel <devel at ntpsec.org> wrote:
> On Mon, Sep 04, 2023 at 02:25:46PM -0700, Gary E. Miller via devel
> > From RHEL:
> > "The RHEL 8 AppStream Lifecycle Page puts the end date of RHEL 8's
> > Python 2.7 package at June 2024."
> > https://access.redhat.com/solutions/4455511
> Hi Gary,
> 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?
> How much does it cost us to maintain python2 support in our own code?
> 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.
> 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.
Dropping support for Python 2 should allow for dropping most of the poly
infrastructure. That code (pylib/poly.py) involves some contortions (see
also ) 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.
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 /carefully/ 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.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the devel