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/ -----------------------------------------------------------------------