[Edu-sig] Learning Python via a browser: looking for a name

[Ian Bicking]

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  /  ianb at colorstudy.com  /  http://blog.ianbicking.org