-
Notifications
You must be signed in to change notification settings - Fork 1.4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
DEP: Drop support for Python 3.8 #3051
Comments
Do you know if there has been such a "quick" support drop on the previous version ? |
The last time, both Python 3.6 and 3.7 where deprecated together on 2023-08-17. Python 3.7 went EOL on 2023-06-27. (Source: https://github.blog/changelog/2023-08-02-deprecation-notice-dependabot-to-drop-support-for-python-3-6-and-3-7/) |
.github/workflows/github-ci.yaml:
Could move this to 3.13, not 3.9? Would only really effect the "pycryptodome" case, since the "none" case is a subset of the standard "cryptography" cases. Advantages are forward looking and maybe (???) faster. |
I do not get this. Could you please elaborate? For moving this to Python 3.13: I do not think that this has substantial benefits for now. Speed should not really matter here, especially since I have seen Python 3.13 having a rather negative impact on the speed of some code (although not necessarily in our cases). |
The "none" case is where "cryptography" and "PyCryptodome" are not used, and we (pypdf) use our own version of ARC4, but do not use AES. So subset was technically the wrong word. If I have understood correctly, we are testing Python 3.8 for ARC4, AES and related stuff using the three variants ( "none", "cryptography", and "PyCryptodome"). Testing on Python 3.13 may be better as this is more forward looking, and more likely to find breaking changes and the like.
When you say speed should not really matter here, that makes sense because these are tests. So, my argument for speed is not relevant here (and as you mention could actually be a slow down). |
Breaking changes in third-party libraries (or missing support for latest Python versions) is rare and ideally not the task of pypdf, although we might implement countermeasures once we got aware of this. Running all tests on the lowest supported Python version ensures that we do not accidentally break stuff. In parallel, I have a custom pipeline which always checks against the latest releases by using an aggressive dependabot configuration, which would just be too much noise for pypdf itself. |
Python 3.8 is EOL since 2024-10-07, id est for about three months. On 2025-02-05, Dependabot might stop updating critical pinned dependencies as per https://github.blog/changelog/2025-01-06-closing-down-notice-dependabot-will-no-longer-support-python-version-3-8/:
In the past, we usually supported EOL Python versions for about one further year, although we have no strong policy for this. (To match the corresponding Ubuntu release cycle, we would have to wait until April 2025 when Ubuntu 20.04 shipping Python 3.8 is going EOL for example.)
The text was updated successfully, but these errors were encountered: