[Python-ideas] Introduce collections.Reiterable
ncoghlan at gmail.com
Mon Sep 23 06:58:08 CEST 2013
On 23 Sep 2013 09:47, "Steven D'Aprano" <steve at pearwood.info> wrote:
> On Sun, Sep 22, 2013 at 12:37:52PM -0400, Terry Reedy wrote:
> > On 9/22/2013 10:22 AM, Nick Coghlan wrote:
> > >The __getitem__ fallback is a backwards
> > >compatibility hack, not part of the formal definition of an iterable.
> > When I suggested that, by suggesting that the fallback *perhaps* could
> > be called 'semi-deprecated, but kept for back compatibility' in the
> > glossary entry, Raymond screamed at me and accused me of trying to
> > change the language. He considers it an intended language feature that
> > one can write a sequence class and not bother with __iter__. I guess we
> > do not all agree ;-).
> Raymond did not "scream", he wrote *one* word in uppercase for emphasis.
> I quote:
> It is NOT deprecated. People use and rely on this behavior. It is
> a guaranteed behavior. Please don't use the glossary as a place to
> introduce changes to the language.
> I agree, and I disagree with Nick's characterization of the sequence
> protocol as a "backwards-compatibility hack". It is an elegant protocol
> for implementing iteration of sequences, an old and venerable one that
> predates iterators, and just as much of Python's defined iterable
> behaviour as the business with calling next with no argument until it
> raises StopIteration. If it were considered *merely* for backward
> compatibility with Python 1.5 code, there was plenty of opportunity to
> drop it when Python 3 came out.
> The sequence protocol allows one to write a lazily generated,
> potentially infinite sequence that still allows random access to items.
> Here's a toy example:
> py> class Squares:
> ... def __getitem__(self, index):
> ... return index**2
> py> for sq in Squares():
> ... if sq > 9: break
> ... print(sq)
> Because it's infinite, there's no value that __len__ can return, and no
> need for a __len__. Because it supports random access to items, writing
> this as an iterator with __next__ is inappropriate. Writing *both* is
> unnecessary, and complicates the class for no benefit. As written,
> Squares is naturally thread-safe -- two threads can iterate over the
> same Squares object without interfering.
And PEP 3119 means you have to decorate it with "@Iterable.register" for
Python to *formally* consider it an iterable (or a third party can do the
registration later). Merely defining __getitem__ is considered
insufficient, since it is possible to define that *without* intending to
create an iterable.
> Python-ideas mailing list
> Python-ideas at python.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Python-ideas