[Python-ideas] Introduce collections.Reiterable

[Neil Girdhar]

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.

Best,
Neil


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)
>> ...
>> 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/20130921/6b30d136/attachment.html>