[Python-ideas] Introduce collections.Reiterable
mistersheik at gmail.com
Sat Sep 21 06:52:29 CEST 2013
We discussed this upthread: I only want "not iterator" if not iterator
promises reiterability. Right now, we have what may be a happy accident
that can easily be violated by someone else.
On Sat, Sep 21, 2013 at 12:50 AM, Andrew Barnert <abarnert at yahoo.com> wrote:
> On Sep 20, 2013, at 21:23, Neil Girdhar <mistersheik at gmail.com> wrote:
> I appreciate the discussion illuminating various aspects of this I hadn't
> considered. Finally, what I think I want is for
> * all sequences
> * all views
> * numpy arrays
> to answer yes to reiterable, and
> * all generators
> to answer no to reiterable.
> All sequences, views, and numpy arrays answer no to iterator (and so do
> sets, mappings, etc.), and all generators answer yes (and so do the
> iterators you get back from calling iter on a sequence, map, filter, your
> favorite itertools function, etc.)
> So you just want "not iterator". Even Haskell doesn't attempt to provide
> negative types like that. (And you can very easily show that it's iterator
> that's the normal type: it's syntactically checkable in various ways--e.g.,
> it.hasattr('__next__'), but the only positive way to check reiterable is
> not just semantic, but destructive.)
> Best, Neil
> On Fri, Sep 20, 2013 at 10:12 PM, Stephen J. Turnbull <stephen at xemacs.org>wrote:
>> Terry Reedy writes:
>> > Dismissing legal code as 'pathological', as more than one person has,
>> > does not cut it as a design principle.
>> But you don't even need to write a class with __getitem__() to get
>> that behavior.
>> >>> l = [11, 12, 13]
>> >>> for i in l:
>> ... print(i)
>> ... if i%2 == 0:
>> ... l.remove(i)
>> >>> l
>> [11, 13]
>> Of course the iteration itself is probably buggy (ie, the writer
>> didn't mean to skip printing '13'), but in general iterables can
>> change themselves.
>> Neil himself seems to be of two minds about such cases. On the one
>> hand, he said the above behavior is built in to list, so it's
>> acceptable to him. (I think that's inconsistent: I would say the
>> property of being completely consumed is built in to iterator, so it
>> should be acceptable, too.) On the other hand, he's defined a
>> reiterable as a collection that when iterated produces the same
>> objects in the same order.
>> Maybe what we really want is for copy.deepcopy to do the right thing
>> with iterables. Then code that doesn't want to consume consumable
>> iterables can do a deepcopy (including replication of the closed-over
>> state of __next__() for iterators) before iterating.
>> Or perhaps the right thing is a copy.itercopy that creates a new
>> composite object as a shallow copy of everything except that it clones
>> the state of __next__() in case the object was an iterator to start
>> Python-ideas mailing list
>> Python-ideas at python.org
>> You received this message because you are subscribed to a topic in the
>> Google Groups "python-ideas" group.
>> To unsubscribe from this topic, visit
>> To unsubscribe from this group and all its topics, send an email to
>> python-ideas+unsubscribe at googlegroups.com.
>> For more options, visit https://groups.google.com/groups/opt_out.
> Python-ideas mailing list
> Python-ideas at python.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Python-ideas