RestrictedPython
RestrictedPython copied to clipboard
Support Python 3.14
Look through the change log of Python 3.14 (once the first release candidate version is released End of July 2025 (see https://peps.python.org/pep-0745/)) for potential issues which need to be handled by RestrictedPython to prevent access to otherwise forbidden data/objects.
There is no need to support new language features of Python 3.14 right now, let's see how they evolve after they can be used,
Open tasks:
- [x] make package installable and fix tests
- [x] Change log:
Allow to use the package with Python 3.14 -- Caution: No security audit has been done so far. - [x] cut an alpha dev release (8.1a1.dev0)
- [ ] security audit after rc1 Python release (detailed instructions)
- [ ] Prepare for a new Python version after its rc1 release (detailed instructions)
- [ ] Create a copy of this ticket for Python 3.15 (first alpha is expected to land October 2025)
IMHO this can be done earlier than the final version. The earliest would be the first beta (no ABI changes, right?) and the latest point would be the first RC.
We usually did the final RestricedPython release after the final Python release to make sure that no late changes (sometimes even during RC time!) have an influence here.
That process always felt rushed to me when you wait until the final release and then it all has to happen quickly (and then no one really has time or motivation, as always). And we always run into annoying issues with packages that depend on RestrictedPython where we have to keep pinning development releases just to be able to run their tests on the new Python version.
I believe the risk of a change that really is relevant to RestrictedPython is extremely low after the first RC is released. I would argue it's OK to start the last steps (security audit etc) as soon as the first RC is out. That gives us time and everything could be finished and packages released in time for the final Python release.
@dataflake Did I understand you correctly that you suggest to pause here until the first RC is out and thus not being able to try the depending packages before that point in time? Or do you just suggest to start the security review earlier?
No that is not what I am saying. You can create alphas and betas without a problem. All I am saying it this: I don't think it makes sense to wait for a final Python release to make a final RestrictedPython release. It is totally fine to work on and create a final RestrictedPython release after the first RC for Python is out.
@dataflake Thank you for the clarification. I updated the ticket description and will now create a dev version which supports 3.14.
RestrictedPython 8.1 is released, @loechel had done the security check and support work for t-strings. The followup issue for Python 3.15 support is at #306