Andre Roberge wrote: > Imagine, if you will, that, through your browswer, you could interact > with the Python tutorial, instead of simply reading it, and really try > Python. For a concrete example, here's a modified snippet from the > tutorial: > #==== > 3.1.1 Numbers > > The interpreter acts as a simple calculator: you can type an > expression at it and it will write the value. Expression syntax is > straightforward: the operators +, -, * and / work just like in most > other languages (for example, Pascal or C); parentheses can be used > for grouping. For example: > > >>>>2+2 > > 4 > BOX(>>>) > #================ > Where BOX(>>>) represents a one-line "box" (html form with text input) > in which you could actually type "2+2", and see that you can reproduce > the actual example.
You might want to look at how trypy (http://trac.pocoo.org/browser/trypy) presents the material, which is in turn based on Try Ruby (http://tryruby.hobix.com/) I actually think the doctest approach is nicer and less linear. > Ok, that shouldn't be too hard to imagine, as there are already a few > apps that can be adapted to do this, the latest being Ian Bicking's > HTConsole. > > Now, imagine if you could also embed some longer examples, no longer > at the interpreter prompt, but as some small scripts, and let the user > edit them. Then, at the press of a button, you could execute them, > and repeat the edit-run cycle as often as you wished, all within your > browser. [This is referred to as TEXTBOX() below.] Note in HTConsole you can embed larger examples as functions; e.g., "from tutorial import *" will bring in all the functions into the current environment, in an editable form. Or load(), which would probably be cleaner in practice. > Again, that shouldn't be too hard to do... > > Then, imagine that you could also have the option to include docTest > quiz as described by Jeff Elkner at > http://dc.ubuntu-us.org/projects/doctest-quiz.php > and mentioned previously on this list. The way you could have this is > to have a webpage that looks as follows: > #========= > Question 1: Write just enough Python code to make the following DocTests pass: > > """ > >>> a = Animal() > >>> a.name > '' > >>> a.friends > [] > """ > TEXTBOX() > #============= > Running this would invoke invoke properly the docTest module, > combining the sample docTest embedded in the page together with the > user written code. > > Imagine if some such tutorials could be designed by anyone, by simply > writing standard html documents, with just a few additional arguments, > e.g. > <p python_type="doctest"> > """ > >>> a = Animal() > >>> a.name > '' > >>> a.friends > [] > """ > </p> Incidentally, I've been planning soon to write a doctest HTML parser. It shouldn't be too hard, I think; doctest is mostly already factored for this. I'll write it as a separate library. The one nuisance is that line numbers don't mean much in HTML, but they are embedded into doctest. I'm guessing I'll have a routine to "convert" a doctest HTML file, from: <pre class="doctest"> >>> foo( ... bar) baz </pre> to: <pre class="doctest"> <span id="line-1"> >>> foo(</span> <span id="line-2"> ... bar)</span> <span id="line-3"> baz</span> </pre> Or... I don't know what. Heck, as long as I'm doing all that, maybe I'll just make the report a modified version of the original test. Prettier anyway. > Finally, imagine if you could have, side-by-side, a TEXTBOX and a > <canvas> area where you could try turtle graphics. All within your > standard webbrowser. Alan Kay's Logo has embedded turtle graphics: http://www.logowiki.net/ -- something perhaps to steal. (I've tried successfully with Firefox 1.5, but in 1.0.7 it isn't working) Doctesting graphics is hard :-/ -- if the graphics were more constrained, it actually wouldn't be so hard. Karel for instance is within the scope of doctestability. Would require some fancy doctest hacking, but at least possible. > The good news is that I have working prototypes for all of the above > *except* the last one - but I am pretty sure I know (in principle) how > to do that one too. [I'm proud to say that I only use Python - not a > single javascript line of code. ;-)] Boo! Javascript rocks! ;) > One small caveat: it runs entirely on a single computer - for security > reasons. But, if there was a way to have a server-side sandbox, it > could be adapted by (I think) changing just one line of code. One thing I'm planning on adding to HTConsole is to allow a user to give a password when starting it up (or, accessible from 127.0.0.1), and then after that a user with access can get a URL that will implicitly give access (one of those things like http://foo.com/access?longsignedstring). This way multiple users can access the same environment; HTConsole 0.2 makes that work a bit better (changes won't get pushed immediately, but if you hit <refresh> you should see the other user's changes) Also IP based restrictions (beyond just 127.0.0.1), which are useful in computer labs. -- Ian Bicking / [EMAIL PROTECTED] / http://blog.ianbicking.org _______________________________________________ Edu-sig mailing list [email protected] http://mail.python.org/mailman/listinfo/edu-sig
