chore(ci,deps): remove PyPy 3.11 support

[kevaundray]

🗒️ Description

Since Python 3.13 (Cpython) is now faster than Python 3.11 (PyPy), we can use Python 3.13/3.14 for the usecases that we were using PyPy for.

🔗 Related Issues or PRs

Closes #1258, #2029, #2055.

✅ Checklist

• All: Ran fast tox checks to avoid unnecessary CI fails, see also Code Standards and Enabling Pre-commit Checks:

  uvx tox -e static

• All: PR title adheres to the repo standard - it will be used as the squash commit message and should start type(scope):.
• All: Considered updating the online docs in the ./docs/ directory.
• All: Set appropriate labels for the changes (only maintainers can apply labels).
• Tests: Ran mkdocs serve locally and verified the auto-generated docs for new tests in the Test Case Reference are correctly formatted.
• Tests: For PRs implementing a missed test case, update the post-mortem document to add an entry the list.
• Ported Tests: All converted JSON/YML tests from ethereum/tests or tests/static have been assigned @ported_from marker.

Cute Animal Picture

[kevaundray]

It seems that its a goal to support 3.11, so still keeping it supported. See #2316

can bump to 3.13 if folks think we want to increase the minimum supported python version

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 84.89%. Comparing base (47ae746) to head (b22a9aa).

Additional details and impacted files

@@               Coverage Diff                @@
##           forks/amsterdam    #2372   +/-   ##
================================================
  Coverage            84.89%   84.89%           
================================================
  Files                  599      599           
  Lines                36719    36719           
  Branches              3780     3780           
================================================
  Hits                 31172    31172           
  Misses                4916     4916           
  Partials               631      631           

Flag	Coverage Δ
unittests	84.89% <ø> (ø)

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[danceratopz]

Removing pypy support is fine from my side (it would close #1258, #2029, #2055) and this PR LGTM.

The breakdown of ethereum-execution downloads by Python implementation over the last 180 days definitely doesn't show many pypy downloads.

Claude told me I could handwave away the "Unknowns" as unlikely to be attributed to PyPy as it's a deliberate choice of a modern toolchain; not sure I 100% agree 😆. Sam would def be using 3.11 and not 3.10 :-).

Implementation	Python	Downloads	%
CPython	3.12	30,737	39.63%
CPython	3.10	25,876	33.36%
CPython	3.11	10,695	13.79%
CPython	3.13	1,623	2.09%
PyPy	3.10	62	0.08%
Unknown	n/a	8,263	10.65%
Other		83	0.11%
Total		77,325
Source https://pypistats.org/packages/ethereum-execution (via BigQuery).

Either way, I don't think we have many PyPy users of ethereum-execution other than Sam.

But as Sam does use PyPy and it seemed important for mainnet sync, I would defer approval of this PR to @SamWilsn.

[danceratopz]

I'd add that we're making a lot changes at the mo 😆 and I don't have the overview of how they all interplay. Perhaps @kevaundray does :-) I mean, how does #2370 impact pypy vs cpython?

Since Python 3.13 (Cpython) is now faster than Python 3.11 (PyPy), we can use Python 3.13/3.14 for the usecases that we were using PyPy for.

Btw, @kevaundray what was statement this based on? It doesn't seem to be consensus in public benchmarks. Is it just the case for our codebase?

Of course, if we don't need pypy (because it's not faster), I'm happy to drop support.

[kevaundray]

I'd add that we're making a lot changes at the mo 😆 and I don't have the overview of how they all interplay. Perhaps @kevaundray does :-) I mean, how does #2370 impact pypy vs cpython?

Since Python 3.13 (Cpython) is now faster than Python 3.11 (PyPy), we can use Python 3.13/3.14 for the usecases that we were using PyPy for.

Btw, @kevaundray what was statement this based on? It doesn't seem to be consensus in public benchmarks. Is it just the case for our codebase?

Of course, if we don't need pypy (because it's not faster), I'm happy to drop support.

Hey ser,

Yeah I was only basing it off of the CI times for testing in this codebase, given pypy is testing about a third of cpython

[danceratopz]

Yeah I was only basing it off of the CI times for testing in this codebase, given pypy is testing about a third of cpython

Fair :) I was just wondering if you had any other specific benchmarks as you've been digging around a lot!

[kevaundray]

Yeah I was only basing it off of the CI times for testing in this codebase, given pypy is testing about a third of cpython

Fair :) I was just wondering if you had any other specific benchmarks as you've been digging around a lot!

Makes sense! -- happy to do a mainnet sync if you have the command -- was mainly using the CI testcases as a proxy for this codebase

[kevaundray]

Spoke with @SamWilsn , who has now merged in #2482 -- so will close this