181Re: [python-iter] Why must an iterator have an __iter__ method? (fwd)
- Mar 14, 2001
> [ Guido van Rossum :]Let's me elaborate:
> > > > We *could* add <next> sniffing, but I believe then we would have to
> > > > bite the bullet and use tp_next and __next__; otherwise the sniffing
> > > > is too fragile (looking for __call__ is clearly a bad idea; looking
> > > > for a next() method also seems a bad idea, see above.)
> > > Why 'looking for __call__ is clearly a bad idea' ?
> [ Guido van Rossum :]
> > Because the presence of __call__ is not enough to be sure that it's an
> > iterator. It could be any old callable.
> Maybe we can use some atribute only for taging iterator.
> So if looking for (say) __iterator_tag__ succeed it is
> iterator, it is callable.
> This way we can use anything callable for iterator insisting
> it's taged as iterator (has attribute __iterator_tag__).
1. I'm all in favor of simple (one pass, read only) iterators as
anything callable. ( and YES, your right, with strong 'concept check',
as they call it in new SGI STL)
- flexibility for implementation of simple iterators
(one pass, read only) or 'iterator-like objects',
coupled with simplicity and efficiency.
(I think, don't now, it's even wel fit for implementation with
- Natural interface when there is the only one job for object.
2. __iterator_tag__ (explicit concept check support) is completly
other iusse. It's motivated and for cheap gains:
(by accident it's even supports 1.:)
(it's extensible: support for wider iterator interface also,
example: writable iterator concept check)
- robustnes (no 'fragile next sniffing' )
- consistent semantic and clearer code
(no confusing '__iter__ functionality' in iterator)
3. So we can achive logicaly prefered (IMHO)
for_loop expresion resolution:
for item in x:
if isIterator(x): # iterator
break # use it
elif hasDefaultIterator(x): # new sequence
x = x.DefaultIterator() # create default iterator for sequence
x = create_iterator_from_getitem(x)
- << Previous post in topic