generator-based exercises are rough

[parmentelat]

release 0.6 comes with an experimental model for building generator-based exercises

we have 2 different and complementary mechanisms to limit / select output from the generator flow

• max_iterations is set on the exercise instance; it acts more like an antiloop, and allows to limit the amount of iterations done no matter what
• islice is set on the GeneratorArgs object and allows to select only a selection of the flow; designed to inspect for example the 1000-th iteration, within the same exercise and same actual parameters passed to the gen-func

within 0.6.0 these 2 mechanisms do not cohabit very nicely; when testing primes() with max_iterations=10_000 everything becomes super-slow
the point is that we need to call list() on the generator output rather early in the process - so that comparisons do the right thing - and it is very likely the point where things go wrong

[parmentelat]

as a follow-up on this issue
release 0.6.1 was attempt to cope with iterators as arguments
issue being that such objects cannot be copied, but we need to copy Args instances so that all runs are isolated from one another

the path looked promising, but eventually I had to back down to 0.6.0 because the few generator-based exercises that I had written - and that I did not yet need this new feature - were not behaving properly, as somehow iterators tended to be used way further than needed

the initial intention was to create a differential exercise. it is still available but the copy_mode='tee' setting is no longer applied to all generator exercises by default, so it needs to be set explicitly so that argument iterators can be copied using itertools.tee()

[parmentelat]

one way to see the negative impact of 0.6.1 is to run the 'primes' exo from e.g. notebook #4 on generators
first example should stop at prime #20, but it goes on until 101 as per max_iterations.