py-pdf
DEP: Drop support for Python 3.8
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/:
On February 5th, 2025, Dependabot will end support for Python version 3.8, which has reached its end-of-life. If you continue to use Python version 3.8, there’s a risk that Dependabot will not create pull requests to update dependencies. To prevent this from happening, please update to a supported release of Python.
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.)
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:
include:
- python-version: "3.8"
use-crypto-lib: "pycryptodome"
- python-version: "3.8"
use-crypto-lib: "none"
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.
since the "none" case is a subset of the standard "cryptography" cases.
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).
since the "none" case is a subset of the standard "cryptography" cases.
I do not get this. Could you please elaborate?
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.
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).
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 and Python 3.14 are not directly related. But yes, I have already started testing with Python 3.14, although not yet here in the original repository. I tend to prefer dropping Python 3.8 first nevertheless.