A RetroSearch Logo

Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Search Query:

Showing content from https://mail.python.org/pipermail/python-dev/2002-August/028404.html below:

PEP 218 (sets); moving set.py to Lib]

[Python-Dev] Re: A `cogen' module [was: Re: PEP 218 (sets); moving set.py to Lib] [Python-Dev] Re: A `cogen' module [was: Re: PEP 218 (sets); moving set.py to Lib]Guido van Rossum guido@python.org
Wed, 28 Aug 2002 16:19:11 -0400
> Oh, come on you two... stop beating up the poor strawman. The reiter()
> function doesn't make a single redundant call to __iter__.  It's just 
> like iter() but ensures in passing that the result is really a fresh 
> iterator.

I'm really sorry.  I had forgotten what exactly your proposal was.  It
is actually very reasonable:

    Proposal: new built-in function reiter()

    def reiter(obj):
        """reiter(obj) -> iterator

    Get an iterator from an object. If the object is already an iterator a
    TypeError exception will be raised. For all Python built-in types it is
    guaranteed that if this function succeeds the next call to reiter() will
    return a new iterator that produces the same items unless the object is
    modified. Non-builtin iterable objects which are not iterators SHOULD
    support multiple iteration returning the same items."""

        it = iter(obj)
        if it is obj:
            raise TypeError('Object is not re-iterable')
        return it

--Guido van Rossum (home page: http://www.python.org/~guido/)



RetroSearch is an open source project built by @garambo | Open a GitHub Issue

Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo

HTML: 3.2 | Encoding: UTF-8 | Version: 0.7.4