Re: snapshotting some instructional scaffolding...
On Tue, May 3, 2011 at 10:07 PM, Kirby Urner <[hidden email]> wrote:
> """ > OST Skunkworks: Freakish Tractor > generator that moves forward to a boundary reading > current character, writing current marker. Fuel > might run out. send protocol may be employed to
> tank up, redirect, change the marker. Farm is an > n x m array, presumably smallish, for interactive > console experiments. > -- Python track, O'Reilly School of Technology > http://www.facebook.com/oreillyschool
> Also: > http://mybizmo.blogspot.com/2011/05/lesson-planning.html > """
As CS teachers know, it's often instructive to start not with a blank canvas but some discrete unit of working code that may be set back to zero (back to factory) at any point.
One then develops forward by adding features, by various
deltas, these being the student projects.
Many curricula focus on game frameworks and branching
Laura and I have done stuff with playing cards in this archive,
and that remains a focus in many a Combinatorics course.
In the case of the above, we're pushing the boundaries of
what generators are good for. Adding a "run out of
fuel" feature has potential is many times we'd like to iterate over a generator up to a certain point. itertools has islice for that.
Here we inject a finite energy budget into the generator
upon initialization. It could terminate for no other reason
that "running out of gas". In a next iteration, the Tractor
becomes a class with a __next__ and an __iter__ method.
Student projects begin from there, again adding features,
or simply making use of as is, as means to other ends.
A subclass of Tractor called a CropCircle participates in
mowing the Mandelbrot Set (or 48 of them do -- I shared a