Type Annotations for RestrictedPython

• [x] I signed and returned the Zope Contributor Agreement, and received and accepted an invitation to join a team in the zopefoundation GitHub organization.
• [x] I verified there aren't any other open pull requests for the same change.
• [x] I followed the guidelines in Developer guidelines.
• [x] I successfully ran code quality checks on my changes locally.
• [x] I successfully ran tests on my changes locally.
• [x] If needed, I added new tests for my changes.
• [x] If needed, I added documentation for my changes.
• [x] I included a change log entry in my commits.

---

If your pull request closes an open issue, include the exact text below, immediately followed by the issue number. When your pull request gets merged, then that issue will close automatically.

Closes #

Please do not unilaterally remove Python 3.9 support. This is done in concert with all other ZF packages.

Please do not unilaterally remove Python 3.9 support. This is done in concert with all other ZF packages.

@dataflake as RestrictedPython is one of the most underlying Package in Zope, that is where removal of Python Versions that are EOL needs to start.

I am not willing to add or accept Python 3.9 Support on RestrictedPython as soon as Pthon 3.14 Support is wanted.

We sould follow https://devguide.python.org/versions/ recommendations and remove Version support as soon as EOL is reached. Users can still use older Versions of Restricted Python if they are on Python 3.9

@dataflake as RestrictedPython is one of the most underlying Package in Zope, that is where removal of Python Versions that are EOL needs to start.

I disagree. We have always done it the other way around. Zope officially declares a Python version unsupported and after that its dependencies can drop it.

I am not willing to add or accept Python 3.9 Support on RestrictedPython as soon as Python 3.14 Support is wanted.

I appreciate your work but I really don't like the fact that you are forcing this issue without even asking anyone before. You do realize that e.g. the Plone 6.0 release series, which is in security support mode until the end of 2027, still uses Python 3.9?

If you had told me beforehand that you were making work on Python 3.14 dependent on dropping 3.9 we could have planned for that. Or I would have said thank you, I'll just do it myself then.

I have and will always do my best to preserve compatibility to base packages. Keeping 3.9 Support in unreasonable at the moment.

As the Plone Community is moving towards typing support for all Packages, this Pull Requests adds typing Annotation and Python 3.14 Support.

Yes we could have done that on seperate Pull requests, but rerssources are limited. Modern Typing is only supported in Python 3.10 and higher. Python 3.9-3.13 Support is given with The RestrictedPython Version Line 7.

And @dataflake saying that this was done with out asking anyone is untrue, I am at the Plone Conf sprint, where most of the underlying maintainace of Packages happen, and spoken and discussed it with relevant stakeholders.

And also let me say that, I am very unhappy with the maintainance of this package. Before me no-one in the community has taken care of this package, even if all of Zope and Plone was depending on this package. I have invested several years or work getting it into maintainable shape and into continious maintainance. Yes that would not be able without the help of @icemac . But I am actually pretty annoyed if people delete almost one third of the documentation and history, because they feel it is not needed anymore, as versions has been dropped.

Another example of this is that I invested a lot of work into make this package maintainable and understandable, with making the NodeTransformer as explicite as possible. And than someone thinks we can reduce the amount of unneccesary code by deleting and implicit calling of not_allowed.

I have added Python 3.9 to be allow with this Pull Request, but I will not solve the errors of that Version.

and for the Zope/Plone Support see https://plone.org/security/update-policy Plone 6.0 may still support 3.9 but will never use any RestrictedPython 8 version, as that would go against the update-policy.

SO I do not see any reasoning for your argument in the first place.

As the Plone Community is moving towards typing support for all Packages, this Pull Requests adds typing Annotation and Python 3.14 Support.

Yes we could have done that on seperate Pull requests, but rerssources are limited. Modern Typing is only supported in Python 3.10 and higher. Python 3.9-3.13 Support is given with The RestrictedPython Version Line 7.

And @dataflake saying that this was done with out asking anyone is untrue, I am at the Plone Conf sprint, where most of the underlying maintainace of Packages happen, and spoken and discussed it with relevant stakeholders.

What I am reading is that you're not discussing with anyone involved in maintaining Zope itself or the Zope Foundation package ecosystem of nearly 300 packages. You're at the Plone conference and speaking to Plone package maintainers who provide you with input about their goals. I don't see any discussion to synchronize these goals with the Zope community, all I see is unilateral decisions and then a refusal to consider other standpoints.

And also let me say that, I am very unhappy with the maintainance of this package. Before me no-one in the community has taken care of this package, even if all of Zope and Plone was depending on this package. I have invested several years or work getting it into maintainable shape and into continious maintainance. Yes that would not be able without the help of @icemac . But I am actually pretty annoyed if people delete almost one third of the documentation and history, because they feel it is not needed anymore, as versions has been dropped.

Why did you not bring up these concerns when that happened and instead try to use it now as an example for how unnamed people other than you are bad at maintaining this package?

Another example of this is that I invested a lot of work into make this package maintainable and understandable, with making the NodeTransformer as explicite as possible. And than someone thinks we can reduce the amount of unneccesary code by deleting and implicit calling of not_allowed.

See above.

I have now merged in master and removed Python 3.9 support again. Please take a look.