Can I copy a generators state and then backtrack to it if necessary?

[Tim Peters]

[Steve Horne]
> Can I copy a generators state and then backtrack to it if necessary?

No, generators implement the iterator interface, and that's all; the
iterator interface doesn't have a copy method.

> To explain what I mean, imagine the following...
>
>   from __future__ import generators
>
>   def test_gen (p) :
>     for i in range (p) :
>       yield i
>
>   def use_gen (p) :
>     i = p.copy ()  #  or some equivalent
>
>     #  Do something that may accept values from p
>
>     p = i   #  Backtrack
>
>     #  Do something that may accept values from p
>
>
>   use_gen (test_gen (50))
>
>
> I know that I could rewrite the use_gen function to accept a function
> rather than a generator, so that it would be called as...
>
>   use_gen (test_gen, 50)
>
> ... and the function parameter could then be evaluated to rederive the
> initial generator state at any time,

There are as many ways to fake it as you can afford hours to dream them up
<0.7 wink>; and don't forget that class methods can be generators too, and
so access instance variables (a very general way to influence the state;
nested scopes add another; see the Knight's Tour solver in
test_generators.py for natural applications of both).

> but this isn't really as flexible> (you can't easily recreate any
> state other than the initial state), and it also seems less intuitive
> to me.

It's not at all clear what p.copy() "should" do, though-- even for simple
iterators --and that's why we're leaving it out, at least at the start.  For
example, the bindings of local variables are part of a generator's state.
What should p.copy() do about *them*?  If a local vrbl is also a generator,
should it (recursively) apply the .copy() method to it too?  Just make
another reference to the current bindings of the locals?  Systematically do
shallow copies of values?  Systematically do deep copies?

> A major use I could think of for this is in applications that need to
> balance searching by depth and by breadth according to some heuristic.
> In addition to the search tree so far, it would be easy to record
> generator states that have only identified some of the branches from a
> particular state - so you could explore this area of the tree
> depth-wise for a bit then nip-back to expand the breadth later. An
> obvious application would be for board games such as chess.

Needs a PEP, and won't go in for 2.2 because I can pretty much guarantee
"one size fits all" won't.  Python generators aren't quite like any other
language's, and so we need more real-life experience with them before
deciding what (if anything) more is truly needed.

in-the-meantime-python-chess-apps-aren't-really-a-major-use<wink>-ly
    y'rs  - tim