Use PEP 3114 __next__ methods

I got very confused recently when I had a security-proxied iterator
using this sort of pattern:

    class Foo:
        def __iter__(self):
            return self

        def __next__(self):
            ...

The value returned from `__iter__` is wrapped in a security proxy, and I
found that unless I used `PURE_PYTHON=1` I got a `ForbiddenAttribute`
exception trying to get the Python-2-style `next` method.

This probably ought to have been noticed and fixed before we dropped
support for Python 2, in which case a transition period of supporting
both method names would have made sense.  Now that we only support
Python 3, I expect that any proxied objects that actually work as
iterators will have a `__next__` method (and perhaps a vestigial `next`
alias for compatibility), so I think we can just jump straight to only
supporting `__next__` for both the C case and the pure-Python case.

The C case is not actually being tested properly at the moment due to an
oversight around the exact handling of the `PURE_PYTHON` environment
variable, but fixing that will require coordinated changes to both
`zope.security` and `zope.proxy`.  I'll deal with that separately.

1 files changed, 4 insertions, 0 deletions

diff --git a/CHANGES.rst b/CHANGES.rst
index 7391d96..7d9d8b3 100644
--- a/CHANGES.rst
+++ b/CHANGES.rst
@@ -5,6 +5,10 @@
 6.2 (unreleased)
 ----------------
 
+- Make ``next()`` on C proxies call ``__next__`` rather than ``next`` (see
+  PEP 3114), and drop support for the Python 2 ``next`` method name from
+  pure-Python proxies.
+
 
 6.1 (2023-01-18)
 ================