On 2023-09-04 17:38, James Browning via devel wrote:
On Sep 4, 2023 14:46, Matthew Selsky via devel <devel@ntpsec.org> wrote:
On Mon, Sep 04, 2023 at 02:25:46PM -0700, Gary E. Miller via devel
wrote:
> 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 [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.
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.
[1] http://www.catb.org/esr/faqs/practical-python-porting/
--
Richard
_______________________________________________
devel mailing list
devel@ntpsec.org
https://lists.ntpsec.org/mailman/listinfo/devel
