Re: invasive patch to drop support for Python 2.5, part 01/03

Charles Cazabon <[email protected]> Thu, 4 Nov 2021 07:37:02 -0600
Newsgroups gmane.mail.getmail.user
Message-ID <YYPh/[email protected]>
Stephen Gildea <[email protected]> wrote:
> getmail currently supports Python 2.3.3 through 2.7, an impressive
> compatibility stretch that covers 16 years of Python, from 2003 to 2019.
> 
> To move getmail compatibility forward to include the year 2021, we are
> going to have to also move up the oldest date.  The attached patch
> starts that process.  It changes almost all occurrences of the "except"
> syntax to that required by Python 3 and allowed since Python 2.6.
> 
> This moves up the oldest Python supported by getmail to 2.6, released in 2008.

This is interesting work; thanks for posting it.

You do say that you plan to add more patches towards Python 3.x compatibility.
But that's basically taking getmail in the same direction as that recent
hostile fork which just ran getmail through 2to3 and then fixed up breakages
as they were found.

My plans for getmail and Python 3.x are not secret; I have explained them on
this list quite a number of times.  It involves a large refactoring, removing
all kinds of cruft from having to add workarounds and missing features that
weren't added to Python until much later, changes to make the code more modern
(my personal coding style has not remained static for 23 years...), and other
changes.  That work is actually somewhere between "major refactoring" and
"rewrite".

getmail-next would then be for Python 3.x systems - probably requiring at
least 3.7, maybe higher - and getmail v5 would remain for those use cases
requiring Python 2.x.  So I'm not sure why I would want to drop support for
Python < 2.6 in getmail v5's codebase.  There are still a lot of ancient
Python versions out there, particularly on embedded systems that continue to
work just fine, but which may never see a Python 2.5 or more recent release,
or legacy systems where compiling a more recent Python is difficult or
impossible due to library dependencies (OpenSSL is frequently mentioned).
There's a reason why I have maintained compatibility back to 2.3.

If I had plans to add significant features to getmail v5, and this work made
implementing those features a lot easier, then I could see the reason for it.
I'm not sure that's clear at this point.

> This patch also removes all checks for the Python version, because they
> no longer work.  The Python 3 syntax can't even be read by Python 2.5,
> so the program wouldn't get as far as displaying the version error.

Nitpick: this is actually easy to accomplish.  You put the version check in a
submodule, and catch ImportError from the getmail script.

> While this loses five years of compatibility, it is still compatible
> with all Python versions released in the last 13 years and all supported
> for the last 10 years.  (Python 2.5 security support ended in 2011.)
> 
> I think this is a reasonable compatibility compromise.

Compromise usually means trading off benefits and drawbacks.  The drawbacks -
mainly just backwards compatibility - are pretty clear, the benefits less so.

Charles
-- 
-----------------------------------------------------------------------
Charles Cazabon
GPL'ed software available at:               http://pyropus.ca/software/
-----------------------------------------------------------------------