[Python-3000] isinstance(., Iterable) vs lookup('__iter__') != None Re: *View in abc.py not inheriting Iterable Re: PEP 3119 - Introducing Abstract Base Classes

Samuele Pedroni pedronis at openendsystems.com
Sat Apr 28 23:01:06 CEST 2007

Guido van Rossum wrote:
> On 4/28/07, Samuele Pedroni <pedronis at openendsystems.com> wrote:
>> Guido van Rossum wrote:
>> > On 4/28/07, Samuele Pedroni <pedronis at openendsystems.com> wrote:
>> >> Shouldn't the various *View in abc.py be Iterables (inherit from
>> >> Iterable) ?
>> >
>> > Oops, it looks like this is a mess. There are two classes
>> > _MappingView. Ignore them for the sake of the PEP. I'll clean them up
>> > later. We probably need fewer mapping classes, nor more...
>> >
>> It seems that something that defines __iter__ should also subclass 
>> Iterable,
>> in this kind of situation where the special method is unique enough 
>> it seems
>> quite repetitive to have to do both. It seems easy to forget to 
>> subclass.
>> Shouldn't now that there are isinstance hooks Iterable be defined again
>> in terms
>> of just checking for the presence of '__iter__' lookup-wise?  I suppose
>> there are some other similar
>> cases, of course in other situations the ABC carry an intention that
>> goes beyond the presence
>> of methods.
> Hm, this certainly sounds like an interesting avenue. So Iterable
> could override isinstance and issubclass that just check for the
> presence of __iter__, and Sized could check for __len__, Hashable
> could check for __hash__, Container could check for __contains__. I
> think the others convey more meaning though; not everything iterable
> sized container is a set (counter-examples are lists and bags). So it
> would affect the "one trick ponies" section only. 
yes, those are the one I had in mind. I think that designs that avoid to
have to repeat oneself unless the repetion really carries some meaning
are better. This would make the transation from current idioms
to 3.0 ABC idioms smoother and more sensible.

> (Should Iterator
> just check for __next__ and leave __iter__ up to the imagination?)
I think it would be a reasonable compromise, there's a trade off between
encouraging to subclass Iterator to get the default __iter__ for free,
vs. having to change current iterators to subclass the right thing to
pass future checks.

More information about the Python-3000 mailing list