[Python-ideas] Introduce collections.Reiterable

[Neil Girdhar]

I check for callable when accepting callbacks because I will call them much
later and raising the error then is harder to track down.  Like I said in
the other mail, your alternative ways of checking reiterability have no
corresponding guarantee that it should work.  Checking other abcs are
supposed to work according to pep 3118.

Neil


On Sat, Sep 21, 2013 at 12:43 AM, Andrew Barnert <abarnert at yahoo.com> wrote:

> 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/20130921/1fc4d170/attachment.html>