[Python-ideas] Introduce collections.Reiterable

[Andrew Barnert]

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)
>> ...
>> 11
>> 12
>> >>> 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
>> with.
>> _______________________________________________
>> Python-ideas mailing list
>> Python-ideas at python.org
>> https://mail.python.org/mailman/listinfo/python-ideas
>> 
>> --
>> 
>> ---
>> You received this message because you are subscribed to a topic in the Google Groups "python-ideas" group.
>> To unsubscribe from this topic, visit https://groups.google.com/d/topic/python-ideas/OumiLGDwRWA/unsubscribe.
>> 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
> https://mail.python.org/mailman/listinfo/python-ideas
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20130920/2160d53a/attachment-0001.html>