Path: csiph.com!usenet.pasdenom.info!news.albasani.net!newsfeed.freenet.ag!news2.euro.net!newsgate.cistron.nl!newsgate.news.xs4all.nl!post.news.xs4all.nl!not-for-mail
Newsgroups: comp.lang.python
Date: Sun, 31 Mar 2013 12:58:15 -0700 (PDT)
In-Reply-To: <mailman.4025.1364759240.2939.python-list@python.org>
Complaints-To: groups-abuse@google.com
Injection-Info: glegroupsg2000goo.googlegroups.com; posting-host=65.78.73.157; posting-account=nhAoTgoAAAAiTaZekt1AoJpN1Rr2agdx
References: <a108caf6-538b-4ca0-978a-97bacc7ca7e8@googlegroups.com> <mailman.4025.1364759240.2939.python-list@python.org>
User-Agent: G2/1.0
MIME-Version: 1.0
Subject: Re: collections.Iterator __subclasshook__ does not check if next() is callable
From: Byron Ruth <bjruth@gmail.com>
To: comp.lang.python@googlegroups.com
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Cc: python-list@python.org
Precedence: list
Message-ID: <mailman.4026.1364759904.2939.python-list@python.org>
Lines: 147
NNTP-Posting-Host: 2001:888:2000:d::a6
Xref: csiph.com comp.lang.python:42400

Thanks for responding Terry.

I can assure you I did not initially realize both the `next` and the `__ite=
r__` methods were implemented when I ran into my original problem. I saw a =
behavior and had to work backwards to realize why it was behaving the way i=
t was (the comparison against Iterator). Once I realized this, the behavior=
 made complete sense. It just dawned on me the fact that `next` was not bei=
ng checked to be callable (I was surprised by this at the time) which is wh=
y I investigated the `Iterator.__subclasshook__` and assumed it was behavin=
g incorrectly based on my assumptions.

On Sunday, March 31, 2013 3:47:07 PM UTC-4, Terry Jan Reedy wrote:
> On 3/31/2013 1:57 PM, Byron Ruth wrote:
>=20
> > I submitted this as bug last night: http://bugs.python.org/issue17584 a=
nd was *honored* to be rejected by Raymond Hettinger. However, I would like=
 feedback on whether my concern (this bug) is justified and clarity if not.
>=20
> >
>=20
> > Consider:
>=20
> >
>=20
> > ```python
>=20
> > class A(object):
>=20
> >      def __init__(self):
>=20
> >          self.r =3D iter(range(5))
>=20
> >      def __iter__(self):
>=20
> >          return self
>=20
> >      @property
>=20
> >      def next(self):
>=20
> >          return next(self.r)
>=20
> > ```
>=20
> >
>=20
> > The `next` method is a property, however:
>=20
>=20
>=20
> A competent Python programmer should not do that. In Py3, the method is=
=20
>=20
> properly renamed '__next__', which should make doing that accidentally=20
>=20
> even less likely.
>=20
>=20
>=20
> >
>=20
> > ```python
>=20
> > from collections import Iterator
>=20
> > a =3D A()
>=20
> > isinstance(a, Iterator) # True
>=20
> > next(a) # TypeError: 'int' object is not callable
>=20
> > ```
>=20
> >
>=20
> > I am using `collections.Iterator` as the means to check if the object i=
s an iterator,
>=20
>=20
>=20
> Being an Iterator only means that it *might* be an iterator.
>=20
>=20
>=20
>  > however I am not sure if that is _root_ problem here. My=20
>=20
> understanding of the iterator protocol is that is assumes the __iter__=20
>=20
> and next *methods* are implemented. In the example, `A.next` is defined=
=20
>=20
> as a property, but is still identified as an iterator. To me, this is=20
>=20
> incorrect behavior since it's not conforming to the iterator protocol=20
>=20
> requirements (i.e. a `next` method, not a property).
>=20
>=20
>=20
> There is more to any protocol than can be statically checked.
>=20
>=20
>=20
> > Raymond stated: "The design of ABCs are to check for the existence to r=
equired named; none of them verify the signature."
>=20
>=20
>=20
> Having the required attributes is currently the definition of being an=20
>=20
> instance of an ABC. Adding 'not a property' would be possible. but=20
>=20
> hardly worthwhile. Checking signatures would be worthwhile, but=20
>=20
> signatures are not yet available to Python for C-coded methods, let=20
>=20
> alone other implementations.
>=20
>=20
>=20
>   I think I understand _why_ this is the case.. but I downstream=20
>=20
> libraries use `collections.Iterator` to determine if an object _is one_:=
=20
>=20
> see=20
>=20
> https://github.com/django/django/blob/master/django/utils/itercompat.py#L=
22-L31
>=20
> >
>=20
> > Who's job is it to check if `next` (and technically `__iter__`) are met=
hods?
>=20
>=20
>=20
> The programmer, and a user who does not trust the competence of the=20
>=20
> programmer. But this is the least of the possible errors.
>=20
>=20
>=20
> --
>=20
> Terry Jan Reedy