Remove pre-Python 3.8 C code

[rtobar]

This is a bit of a big one, but it's mostly removal of dead code anyway, so hopefully it's not too controversial, and well received.

While doing some further code inspection today to re-tackle #86 I realised that there's still a fair bit of code in the C extension, and in the C extension generator, for Python < 3.8. Since 3.8 is the minimum supported version, it makes sense to remove that now-dead code in favour of a less complex codebase.

In order to make this a bit more digestible I split this work in two commits: one focuses on removing support for Python <3, and another for <3.8. Many of these changes are big #if blocks that could easily be removed. In a few places there were macros that were defined differently depending on the Python version, that would have now been left with a single definition. In these cases I removed the macro altogether in favour of using the direct Python C API or idiom as required (e.g., all the PyText_* macros are now PyUnicode_* calls, etc).

Both commits are (I think) correctly self-contained, at least locally they individually both compile, install and test correctly. So in case something breaks it should be easy to bisect back.

[arigo]

See #113 for my personal stance on this issue. @nitzmahone If wants to merge this anyway, go ahead.

[rtobar]

@arigo thanks for that input. I also maintain two libraries for which I kept 2.7 support until not too long ago, but finally decided to drop it, with the rationale being that 2.7 users still can use the old versions without lacking much functionality anyway. Kind-of-supporting 2.7 (or anything other than what setup.py states) will add a maintenance cost that officially you shouldn't need to pay.

I'm not sure if you're aware of this, but have a look at https://pypistats.org/packages/cffi. Seeing those numbers was also something that prompted me to drop support for <1% of users, who again can still download earlier versions of my library. Removing hundreds of lines of C code and macros I think pays the price.

My opinion only of course, if you decide you want to keep the code that's fine, you know your audience and needs better, I won't be pushing back.

[nitzmahone]

Yeah, especially with the very deep inspection and review of all the code that's going to be necessary for proper support of free-threaded Python builds, I'm all for minimizing compatibility code in the active development branches for Python versions that aren't supported/tested.

My experience has repeatedly taught me: if it's not getting tested, it's probably broken...

The old branches of course aren't going anywhere, so if someone really needs to make something work on a long-dead Python version, they can always install an older release or backport fixes to a private fork. We've had several firedrills in recent memory caused by "dead but still called" code breaking suddenly, so I'm quite happy to be more aggressive about cleaning that stuff up for 1.18 and beyond. Thanks!

[rtobar]

Thanks @nitzmahone, that sounds pretty good to me :)

I have been building some further changes on top of these in the hopes that they'd be merged. Based on your message I'll continue under that assumption.

Would you be happy for a similar effort in the python codebase?

[rtobar]

Gentle ping here to see if the intention of doing this clean-up is still there, thanks! I've just also rebased on top of the latest main branch.

[rtobar]

Another gentle ping after a few months of inactivity

[mattip]

I think it would be fine to remove pre-python3 from the src/c code and the vengine_cpy.py code for one PR. There is still a need to somewhat support Python-2 for PyPy-2, which still needs CFFI, even though PyPy vendors CFFI into its codebase. Once we do a first cleanup, we can see what is left.

[mattip]

Rereading #113, I think we should release 1.18 as the last version to still support Python2, and merge something like this PR together with the free-threading code for a new version (1.19? 2.0?). Then people who still wish to use CFFI on Python2 can pin it to 1.18

[nitzmahone]

I think we should release 1.18 as the last version to still support Python2, and merge something like this PR together with the free-threading code for a new version (1.19? 2.0?).

Is there actually anything unreleased or pending merge to main that's apropos for the older pypy branches? If not, the 1.17 branch is still there (and worst case, we could always backport whatever for a 1.17.2 in the future). IIUC the desire for a published pre-release with free-threaded support is the only time-sensitive item right now, so it'd be nice to avoid the churn of doing a 1.18 with nearly no changes and 1.19 with FT support concurrently.

[nitzmahone]

Another thought: for the pypy branches that would be orphaned by removal of old code from main- could their "current CFFI" checks be retargeted to the release-1.17 branch (as the last branch that would contain updates they could sync)? Then main going forward (which gets branched off for 1.18, 2.0, or whatever, don't care what we call it) can have old code ripped out at our leisure, and anything critical in the future that might be needed by the older pypy branches can just be backported to the 1.17 branch (with or without tagging/release, TBD).

[arigo]

My 2 cents: it would be nice if removing-Python-2-support and free-threading-support would both be released into cffi 2.0. It makes it clearer IMHO that it's the first couple of major changes to cffi that occurred for a long time. PyPy2 and users of old CPythons could be sticking with the latest cffi 1.x version. Future updates to cffi 2.0 would only need to be ported to PyPy3, which might remove a few hurdles. The jump to version 2.0 makes it clear when that change occurred.

[mattip]

it'd be nice to avoid the churn of doing a 1.18

OK, this is reasonable.

could their "current CFFI" checks be retargeted to the release-1.17 branch

Good idea.

It would be nice if removing-Python-2-support and free-threading-support would both be released into cffi 2.0.

We could do 2.0 with free-threaded support and partial Python2 cleanup (i.e. what is needed to make the merge of #178 easier) while declaring it no longer supports Python2. Then we could continue the cleanup in a 2.1. This would allow a faster release of the 2.0 free-threading support.

[rtobar]

I've been reading this these last messages with interest. Please let me know if you want me to rebase these changes on top of the latest main.

For those who haven't seen the detail, this PR has two commits:

• The first removes C code for python 2
• The second removes C code for python < 3.8

If we go ahead, do we want to:

• Keep both commits
• Declare 3.8 and unsupported, since that python version is discontinued. Maybe it's been removed already from cffi, I haven't checked.
• Remove C code for python 3.8

[mattip]

I would prefer to separate the two commits. If these statistics can be believed, 3.8 still has about a 10% share on urllib3 downloads on PyPI

[mattip]

… although in the pyproject.toml there is already this which came in PR #129:

cffi/pyproject.toml

Line 15 in 67a170d

requires-python = ">=3.9"

@nitzmahone was that intentional?