[Python-Dev] Re: Reiterability

[Guido van Rossum]

> Yes, if we specify an iter's __copy__ makes an independent iterator,
> which is surely the most useful semantics for it, then any weird iterator
> whose index is in fact mutable can copy not-quite-shallowly and offer
> the same useful semantics.  I'm not sure where that leaves generator
> made iterators, which don't really know which parts of the state in their
> saved frame are "index", but having them just punt and refuse to copy
> themselves shallowly might be ok.

I thought we already established before that attempting to guess wihch
parts of a generator function to copy and which parts to share is
hopeless.  generator-made iterators won't be __copy__-able, period.

I think this is the weakness of this cloning business, because it
either makes generators second-class iterators, or it makes cloning a
precarious thing to attempt when generators are used.  (You can make a
non-cloneable iterator cloneable by wrapping it into something that
buffers just those items that are still reacheable by clones, but this
can still require arbitrary amounts of buffer space.  The problem is
that using a generator as a filter in a pipeline of iterators makes
the result non-cloneable, even if the underlying iterator is
cloneable.  I'm thinking of situations like

  def odd(it):
      while True:
          it.next()
          yield it.next()

  it = odd(range(1000))
  it2 = clone(it)

Here we'd wish the result could be the same as that of

  tmp = range(1000)
  it = odd(tmp)
  it2 = odd(tmp)

but that can't be realized.


> Sure, it might.  Perhaps the typical use case would be one in which
> an iterator gets deepcopied "incidentally" as part of the deepcopy
> of some other object which "happens" to hold an iterator; if
> iterators knew how to deepcopy themselves that would save some work
> on the part of the other object's author.  No huge win, sure.  But
> once the copy gets deep, generator-made iterators should also have
> no problem actually doing it, and that may be another middle-size
> win.

I still don't think deep-copying stack frames is a business I'd like
to be in.  Too many tricky issues.

--Guido van Rossum (home page: http://www.python.org/~guido/)