<div dir="ltr">I'm happy with iterable and not iterator if it comes with a promise.  Then my first ABC is what what I probably want.  If not, then I think it's better to do something lke<div><br></div><div><div>class Reiterable(collections.Iterable,</div>

<div>                 metaclass=collections.abc.ABCMeta):</div><div>    @classmethod</div><div>    def __subclasshook__(cls, subclass):</div><div>        if (issubclass(subclass, collections.MappingView)</div><div>            or issubclass(subclass, collections.Sequence)</div>

<div>            or issubclass(subclass, collections.Set)</div><div>            or issubclass(subclass, collections.Mapping)):</div><div>            return True</div><div>        return NotImplemented</div></div><div><br>

</div><div>Other classes can be added with register.</div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Sat, Sep 21, 2013 at 3:04 AM, Andrew Barnert <span dir="ltr"><<a href="mailto:abarnert@yahoo.com" target="_blank">abarnert@yahoo.com</a>></span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="auto"><div class="im"><div>On Sep 20, 2013, at 21:52, Neil Girdhar <<a href="mailto:mistersheik@gmail.com" target="_blank">mistersheik@gmail.com</a>> wrote:</div>

<div><br></div><blockquote type="cite"><div><div dir="ltr">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.</div>

</div></blockquote><div><br></div></div><div>And if you define your new ABC, it can be just as easily violated by someone else. In fact, it will be violated in the exact _same_ cases. There's no check you can do besides the reverse of the checks done by iterator.</div>

<div><br></div><div>More importantly, it's not just "a happy accident". I've asked repeatedly if anyone can come up with a single example of a non-iterator, non-reiterable iterator, or even imagine what one would look like, and nobody's come up with one. And it's not like iterators are some new feature nobody's had time to explore yet.</div>

<div><br></div><div>So, in order to solve a problem that doesn't exist, you want to add a new feature that wouldn't solve it any better than what we have today.</div><div><div class="h5"><br><blockquote type="cite">

<div><div dir="ltr">

<div>Best,</div><div>Neil</div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Sat, Sep 21, 2013 at 12:50 AM, Andrew Barnert <span dir="ltr"><<a href="mailto:abarnert@yahoo.com" target="_blank">abarnert@yahoo.com</a>></span> wrote:<br>



<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="auto"><div><div>On Sep 20, 2013, at 21:23, Neil Girdhar <<a href="mailto:mistersheik@gmail.com" target="_blank">mistersheik@gmail.com</a>> wrote:</div>



<div><br></div><blockquote type="cite"><div><div dir="ltr"><div>I appreciate the discussion illuminating various aspects of this I hadn't considered. Finally, what I think I want is for<br></div><div>* all sequences</div>



<div>* all views</div><div>* numpy arrays</div>

<div>to answer yes to reiterable, and</div><div>* all generators</div><div>to answer no to reiterable.</div></div></div></blockquote><div><br></div></div>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.)<div>



<br></div><div>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.)</div>



<div><div><div><br></div><div><div><div><blockquote type="cite"><div><div dir="ltr"><div class="gmail_extra">Best, Neil<br><br><div class="gmail_quote">On Fri, Sep 20, 2013 at 10:12 PM, Stephen J. Turnbull <span dir="ltr"><<a href="mailto:stephen@xemacs.org" target="_blank">stephen@xemacs.org</a>></span> wrote:<br>





<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div>Terry Reedy writes:<br>
<br>
 > Dismissing legal code as 'pathological', as more than one person has,<br>
 > does not cut it as a design principle.<br>
<br>
</div>But you don't even need to write a class with __getitem__() to get<br>
that behavior.<br>
<br>
>>> l = [11, 12, 13]<br>
>>> for i in l:<br>
...  print(i)<br>
...  if i%2 == 0:<br>
...   l.remove(i)<br>
...<br>
11<br>
12<br>
>>> l<br>
[11, 13]<br>
>>><br>
<br>
Of course the iteration itself is probably buggy (ie, the writer<br>
didn't mean to skip printing '13'), but in general iterables can<br>
change themselves.<br>
<br>
Neil himself seems to be of two minds about such cases.  On the one<br>
hand, he said the above behavior is built in to list, so it's<br>
acceptable to him.  (I think that's inconsistent: I would say the<br>
property of being completely consumed is built in to iterator, so it<br>
should be acceptable, too.)  On the other hand, he's defined a<br>
reiterable as a collection that when iterated produces the same<br>
objects in the same order.<br>
<br>
Maybe what we really want is for copy.deepcopy to do the right thing<br>
with iterables.  Then code that doesn't want to consume consumable<br>
iterables can do a deepcopy (including replication of the closed-over<br>
state of __next__() for iterators) before iterating.<br>
<br>
Or perhaps the right thing is a copy.itercopy that creates a new<br>
composite object as a shallow copy of everything except that it clones<br>
the state of __next__() in case the object was an iterator to start<br>
with.<br>
<div><div>_______________________________________________<br>
Python-ideas mailing list<br>
<a href="mailto:Python-ideas@python.org" target="_blank">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" target="_blank">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></div>
</div></blockquote><blockquote type="cite"><div><span>_______________________________________________</span><br><span>Python-ideas mailing list</span><br><span><a href="mailto:Python-ideas@python.org" target="_blank">Python-ideas@python.org</a></span><br>



<span><a href="https://mail.python.org/mailman/listinfo/python-ideas" target="_blank">https://mail.python.org/mailman/listinfo/python-ideas</a></span><br></div></blockquote></div></div></div></div></div></div></blockquote>



</div><br></div>
</div></blockquote></div></div></div></blockquote></div><br></div>