Guido van Rossum wrote: > On 4/28/07, Samuele Pedroni <[EMAIL PROTECTED]> wrote: >> Guido van Rossum wrote: >> > On 4/28/07, Samuele Pedroni <[EMAIL PROTECTED]> 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. _______________________________________________ Python-3000 mailing list [email protected] http://mail.python.org/mailman/listinfo/python-3000 Unsubscribe: http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
