Consider:

```python
class A(object):
    def __init__(self):
        self.r = iter(range(5))
    def __iter__(self):
        return self
    @property
    def next(self):
        return next(self.r)
```

The `next` method is a property, however:

```python
from collections import Iterator
a = A()
isinstance(a, Iterator) # True
next(a) # TypeError: 'int' object is not callable
```

Sorry, this isn't bug.  The design of ABCs are to check for the existence to required named; none of them verify the signature.

Understood. I am not sure it is appropriate to follow-up with a question here, but would this be a downstream issue? My understanding of the iterator protocol is that is assumes the __iter__ and next methods are implements. In the example, the next method is defined as a property, but is still identified as an iterator. This seems an incorrect _behavior_ somewhere, although I may have assumed the incorrect place.

It's the nature of duck typing in a dynamic language.  You can tell whether something is present but can't tell whether it words correctly until you call it.

For example, in Python 3, all objects have __lt__ defined, but all it does is return NotImplemented.  So, you can't really tell whether something is orderable until you make the less-than call.

In your case, the rule is that if "next" is present, we assume that it is iterable, but it won't be until it is called that we can tell whether it is implemented correctly (i.e. is callable with zero arguments, returns a value, and raises StopIteration when done).

Thank you for the education. I didn't think about duck-typing extending to the level of whether or not something is callable.. then again the property _could_ return a callable and it would be transparent to the caller.

I responded to this on python-list.