[Python-ideas] Introduce collections.Reiterable
mistersheik at gmail.com
Sat Sep 21 08:56:29 CEST 2013
On Sat, Sep 21, 2013 at 2:25 AM, Stephen J. Turnbull <stephen at xemacs.org>wrote:
> Neil Girdhar writes:
> > 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,
> > and similarly if something is reiterable before iterating it and
> > exhausting. That is the purpose of collections.abc,
> I don't think so. It's documented that way:
> This module provides abstract base classes that can be used to
> test whether a class provides a particular interface; for example,
> whether it is hashable or whether it is a mapping.
> But I wouldn't do explicit testing with isinstance, but rather use
> implicit assertions (at instantiation time) by deriving from the ABC.
> I don't see how Reiterable could be adapted to this style of
> programming because the API of iterables is basically fixed (support
> __iter__ or __getitem__).
Wouldn't you need to define a new ABC to do this?
Here's one possibility with Tim's iterable and not iterator:
def __subclasshook__(cls, subclass):
and not issubclass(subclass, collections.Iterator)):
for obj in [list(), tuple(), dict(), set(), range(4),
(x * x for x in range(4))]:
Another possibility would be to explicitly register Views and so on using
> > and that's what I thought we were discussing.
> You were, I agree. But you proposed a new API, which pretty well
> guarantees many discussants will take a more global view, like "do the
> use cases justify this addition?"
It's a good point. I think if I'm the only with this problem, then the
answer is clearly no. I will just cast to list and so what if it's a
little bit slower in some cases. How could I know that I was the only one
with this problem?
> Another such question is "what exactly is the specification?" Tim
> Delany, for example, AIUI doesn't have a problem with saying that any
> iterable is reiterable, because it won't raise an exception if the
> program iterates it after exhaustion. It simply does nothing, but in
> some cases that's perfectly acceptable. I know you disagree, and I
> don't think that's a useful definition. Still it demonstrates the
> wide range of opinions on what "reiterable" can or should guarantee.
Yes, agreed that there are a wide range of reasonable opinions.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Python-ideas