<br><br><div class="gmail_quote">On Thu, Mar 4, 2010 at 05:23, Nick Coghlan <span dir="ltr"><<a href="mailto:ncoghlan@gmail.com">ncoghlan@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">

<div class="im">spir wrote:<br>
> Hello,<br>
><br>
> (1) I do not understand an iterable type's __iter__() method to be<br>
> compulsary. Actually, each time I have defined one, I had to write:<br>
> def __iter__(self): return self So, I guess that if python does not<br>
> find __iter__(), but the object defines next(), then by default the<br>
> said object could be used as its own iterator. This is what I<br>
> understand by "iterable" and next() is the required method for it. Or<br>
> even better: only if the object does not define next(), then python<br>
> falls back to looking for __iter__(). Is there any obstacle for this<br>
> I cannot see? Side-question: In which cases is it necessary to define<br>
> the iterator as a separate object?<br>
<br>
</div>Almost all containers should use a separate object for their iterators.<br>
Note that this is already the case for all of Python's standard<br>
container types.<br></blockquote><div><br></div><div>There is also the issue of backwards-compatibility when iterators were introduced. Just because someone decided to have a method named next() when iterators were introduced does not mean they intended for it to be viewed as a sequence. Requiring an iterable to define __iter__() took care of the ambiguity.</div>

<div><br></div><div>-Brett</div><div><br></div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<br>
The reason relates to the __reset__ suggestion you describe later in<br>
your message: How do I reset an iterator over a list? Easy, just call<br>
iter() again - it will give me a fresh iterator that starts at the<br>
beginning without affecting the list or my original iterator. By<br>
producing a fresh object for each invocation of __iter__ the state of<br>
the iterators is decoupled from the state of the underlying object which<br>
is generally a good thing from a program design point of view.<br>
<br>
(See Eric's suggestion regarding the use of generators as __iter__<br>
methods to easily achieve this behaviour)<br>
<br>
Objects with significant state that are also their own iterators are<br>
actually quite rare. File objects certainly qualify (since they base<br>
their iteration off the file object's file pointer), but I can't think<br>
of any others off the top of my head.<br>
<br>
Cheers,<br>
Nick.<br>
<font color="#888888"><br>
--<br>
Nick Coghlan   |   <a href="mailto:ncoghlan@gmail.com">ncoghlan@gmail.com</a>   |   Brisbane, Australia<br>
---------------------------------------------------------------<br>
</font><div><div></div><div class="h5">_______________________________________________<br>
Python-ideas mailing list<br>
<a href="mailto:Python-ideas@python.org">Python-ideas@python.org</a><br>
<a href="http://mail.python.org/mailman/listinfo/python-ideas" target="_blank">http://mail.python.org/mailman/listinfo/python-ideas</a><br>
</div></div></blockquote></div><br>