Is python2 dead?

[Richard Laager]

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
>     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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ntpsec.org/pipermail/devel/attachments/20230904/c9f4f357/attachment.htm>