[Python-ideas] Introduce collections.Reiterable

[Neil Girdhar]

Whoa!  I'm not trying to be stubborn!! I'm just suggesting that what we
have today is find if the problem is isolated.


On Sat, Sep 21, 2013 at 3:21 AM, Neil Girdhar <mistersheik at gmail.com> wrote:

> 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
>
> class Reiterable(collections.Iterable,
>                  metaclass=collections.abc.ABCMeta):
>     @classmethod
>     def __subclasshook__(cls, subclass):
>         if (issubclass(subclass, collections.MappingView)
>             or issubclass(subclass, collections.Sequence)
>             or issubclass(subclass, collections.Set)
>             or issubclass(subclass, collections.Mapping)):
>             return True
>         return NotImplemented
>
> Other classes can be added with register.
>
>
> On Sat, Sep 21, 2013 at 3:04 AM, Andrew Barnert <abarnert at yahoo.com>wrote:
>
>> On Sep 20, 2013, at 21:52, Neil Girdhar <mistersheik at gmail.com> wrote:
>>
>> 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.
>>
>>
>> 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.
>>
>> 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.
>>
>> 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.
>>
>>  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/9a972a9e/attachment-0001.html>