Loading ...
Sorry, an error occurred while loading the content.

181Re: [python-iter] Why must an iterator have an __iter__ method? (fwd)

Expand Messages
  • gzeljko
    Mar 14, 2001
      > [ Guido van Rossum :]
      > > > > 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.)
      > [gzeljko:]
      > > > 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.
      > [gzeljko:]
      > 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__).

      Let's me elaborate:

      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
      continuations ?)
      - 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:
      - flexibility
      (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:

      while 1:
      if isIterator(x): # iterator
      break # use it
      elif hasDefaultIterator(x): # new sequence
      x = x.DefaultIterator() # create default iterator for sequence
      elif isOldSequence(x):
      x = create_iterator_from_getitem(x)
      raise TypeError


    • Show all 12 messages in this topic