i like your idea better for the reason that each example is located
near its code, so a failure could be detected and the user sent to
where the problem __may__ lie.

as for interactive testing being the best mode, i agree for short
pieces of code i go to the interpreter, hack around, and then paste a
goodie into my module.

but for long winded code with many dependent pieces (a ray tracer
firing and bouncing rays around reflecting and refracting surfaces) i
tend to test only some larger subset -- for example, the initial ray
and the final ray through a refracting prism -- by running a script
and examining output.

but i guess there is a whole art to figuring out at what granularity
one should be testing (and re-testing) pieces of code (functions, a
few lines, classes, etc). i am still learning about this after coding
for 26 years, and still feel i have too much to learn.

<rant> finally, what i like best about your idea and design is that it
further encourages documentation, visible examples, and testing right
within the code base. i feel so stringly taht in the age of
internetwide development of code, all these things must be integrated
INTO THE SOURCE FILE to be really useable.

sometimes i tire so of clicking over to the browser to read the
doc.html, clicking to the README to look at the example, clicking to
xemacs to look at the source, clicking to the xterm to look at a
python interpreter. etc. etc. just as structs (classes) were created
by divine inspiration (intervention?)  to collect different but
related values (and functions), so too should open source code gather
all its parts together.  </rant>

nice work tim.....