<div dir="ltr">Why not just add one line?<div><br><div>def __iter__(self): return (self.__getitem__(i) for i in itertools.count())</div></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Sun, Sep 22, 2013 at 7:46 PM, Steven D'Aprano <span dir="ltr"><<a href="mailto:steve@pearwood.info" target="_blank">steve@pearwood.info</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">On Sun, Sep 22, 2013 at 12:37:52PM -0400, Terry Reedy wrote:<br>
> On 9/22/2013 10:22 AM, Nick Coghlan wrote:<br>
><br>
> >The __getitem__ fallback is a backwards<br>
> >compatibility hack, not part of the formal definition of an iterable.<br>
><br>
> When I suggested that, by suggesting that the fallback *perhaps* could<br>
> be called 'semi-deprecated, but kept for back compatibility' in the<br>
> glossary entry, Raymond screamed at me and accused me of trying to<br>
> change the language. He considers it an intended language feature that<br>
> one can write a sequence class and not bother with __iter__. I guess we<br>
> do not all agree ;-).<br>
<br>
</div>Raymond did not "scream", he wrote *one* word in uppercase for emphasis.<br>
I quote:<br>
<br>
    It is NOT deprecated.   People use and rely on this behavior.  It is<br>
    a guaranteed behavior.  Please don't use the glossary as a place to<br>
    introduce changes to the language.<br>
<br>
<br>
I agree, and I disagree with Nick's characterization of the sequence<br>
protocol as a "backwards-compatibility hack". It is an elegant protocol<br>
for implementing iteration of sequences, an old and venerable one that<br>
predates iterators, and just as much of Python's defined iterable<br>
behaviour as the business with calling next with no argument until it<br>
raises StopIteration. If it were considered *merely* for backward<br>
compatibility with Python 1.5 code, there was plenty of opportunity to<br>
drop it when Python 3 came out.<br>
<br>
The sequence protocol allows one to write a lazily generated,<br>
potentially infinite sequence that still allows random access to items.<br>
Here's a toy example:<br>
<br>
<br>
py> class Squares:<br>
...     def __getitem__(self, index):<br>
...         return index**2<br>
...<br>
py> for sq in Squares():<br>
...     if sq > 9: break<br>
...     print(sq)<br>
...<br>
0<br>
1<br>
4<br>
9<br>
<br>
<br>
Because it's infinite, there's no value that __len__ can return, and no<br>
need for a __len__. Because it supports random access to items, writing<br>
this as an iterator with __next__ is inappropriate. Writing *both* is<br>
unnecessary, and complicates the class for no benefit. As written,<br>
Squares is naturally thread-safe -- two threads can iterate over the<br>
same Squares object without interfering.<br>
<span class="HOEnZb"><font color="#888888"><br>
<br>
<br>
--<br>
Steven<br>
</font></span><div class="HOEnZb"><div class="h5">_______________________________________________<br>
Python-ideas mailing list<br>
<a href="mailto:Python-ideas@python.org">Python-ideas@python.org</a><br>
<a href="https://mail.python.org/mailman/listinfo/python-ideas" target="_blank">https://mail.python.org/mailman/listinfo/python-ideas</a><br>
<br>
--<br>
<br>
---<br>
You received this message because you are subscribed to a topic in the Google Groups "python-ideas" group.<br>
To unsubscribe from this topic, visit <a href="https://groups.google.com/d/topic/python-ideas/OumiLGDwRWA/unsubscribe" target="_blank">https://groups.google.com/d/topic/python-ideas/OumiLGDwRWA/unsubscribe</a>.<br>
To unsubscribe from this group and all its topics, send an email to <a href="mailto:python-ideas%2Bunsubscribe@googlegroups.com">python-ideas+unsubscribe@googlegroups.com</a>.<br>
For more options, visit <a href="https://groups.google.com/groups/opt_out" target="_blank">https://groups.google.com/groups/opt_out</a>.<br>
</div></div></blockquote></div><br></div>