[Python-ideas] Introduce collections.Reiterable

[Andrew Barnert]

On Sep 20, 2013, at 21:16, Neil Girdhar <mistersheik at gmail.com> wrote:

> You're right that you should go ahead and use something however you want to.  However, there are plenty of times where you can't do that, e.g., you want to know if something is callable before calling it,

Why? What's the harm in just calling it and handling the exception? And surely, if you really need to LBYL here, you need to know that it's callable with the argument you plan to pass it. 

There are good uses for checking if something is callable, but this isn't a good example. And it's very different from your other example.

> and similarly if something is reiterable before iterating it and exhausting.

This one is different. You can't just handle failure, because (a) there's no unambiguous sign of failure, and (b) it's too late to deal with it if you've already exhausted the iterator. 

However, if you just turn the test around, it _is_ syntactically checkable: if "isinstance(it, Iterator)", or "iter(it) is it" or "hasattr(it, __next__)" or "next(it)" doesn't raise... then you have to do a single-pass algorithm or tee the values or make a list or whatever.

Either Reiterable is just Iterable and not Iterator (barring any flaws in the definition of Iterable, which is a separate problem), or it's not an abstract type.

And if it's just Iterable and not Iterator, besides being complicated to implement (you can't inherit from the negation of a class), it's also more complicated to use. The obvious use case is: If you get an Iterator, you have to tee, make a list, use a one-pass algorithm instead of two-pass, whatever. Rewriting that instead as if you get an Iterable but it's not a Reiterable buys you nothing but verbosity. Turning it around so if you get a Reiterable you can skip the fallback just means a double negative that's harder to process.

>  That is the purpose of collections.abc, and that's what I thought we were discussing.  Could you make mistakes trying to look ahead like this?  Sure.  An object could appear callable only to raise NotImplementedError on calling it.  Looking ahead does not have to be foolproof.  This is Python, and of course (almost) *any test* can be fooled.  That doesn't just go for reiterability, it goes for callability as well.
> 
> Best,
> Neil
> 
> 
> On Sat, Sep 21, 2013 at 12:09 AM, Steven D'Aprano <steve at pearwood.info> wrote:
>> On Sat, Sep 21, 2013 at 12:00:14AM -0400, Neil Girdhar wrote:
>> > If someone allows their class to fail the standardized test for
>> > Iterable/Reiterable/Sequence, that class doesn't deserve to be treated as
>> > one.  (Anyone can register their class as a subclass of the ABCs, or more
>> > simply inherit from one.)
>> 
>> This is Python, and duck-typing rules, not Java-like type checking. If
>> you want a language with strict type checking designed by theorists, try
>> Haskell.
>> 
>> The ultimate test in Python of whether something is iterable or not is
>> to try iterating over it, and see if it succeeds or not. If it iterates
>> like a duck, that's good enough to be treated as a duck.
>> 
>> 
>> --
>> Steven
>> _______________________________________________
>> 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/96f5fd06/attachment-0001.html>