[pydotorg-www] project plan

[Andre Roberge]

On Wed, Apr 21, 2010 at 1:31 PM, Michael Foord <mfoord at python.org> wrote:

> On 21/04/2010 18:25, skip at pobox.com wrote:
>


>
>      >>  - Would Google App Engine be a suitable environment for an
>> interactive
>>     >>  Python exploratorium?
>>     >>
>>
>>     Michael>  I'd rather not have our core services dependent on external
>>     Michael>  providers - but am not *strongly* against it for some of the
>>     Michael>  details.
>>
>> I only mentioned GAE because presumably they've solved the problem of
>> someone entering something simple like
>>
>>     print 1000 ** 1000 ** 1000
>>
>>
>
> Ah - you're talking about an "interactive Python exploratorium", I missed
> that. Yes, implementing it on top of google app engine would be sensible.
>
> If you're not ideologically opposed to Silverlight then I have already
> implemented something like this called "Try Python" (unfortunately not yet
> compatible with Silverlight 4 which has just been released - I need a free
> weekend): http://www.trypython.org/
>
> The advantage of Silverlight is that the code runs on the client not the
> server. The disadvantage is that it is only installed on 50% of browsers and
> has poor Linux support (works great on the Mac though).
>
> [snip]

> which will likely take awhile to run.  GAE probably also has more hardware
> available so that the above sort of construct (if it hasn't been addressed)
> is unlikely to be an effective denial-of-service attack.  At most the PSF
> will probably devote a few boxes to such an application.  Execute that a
> few
> times and things can go to pot pretty quickly.  Not to mention
> security/sandbox issues.
>
>
If I may jump in, this is an issue that I've been thinking about for 2 or 3
years at least.

I can think of a few solutions - none of which are entirely satisfactory.

1. Use Crunchy (http://code.google.com/p/crunchy) to transform an otherwise
static tutorial (like the existing Python tutorial) into an interactive
Python session.  This works with the existing tutorial - except for one
small "obscure" unicode example where the output from Crunchy does not match
the output from the existing tutorial due to a Crunchy "feature".
(essentially, Crunchy encodes an otherwise "raw" unicode string).   This
works for both Python 2.x and 3.x.
The HUGE disadvantage of this approach is that it requires the user to first
download Python and Crunchy.

2. Port Crunchy to the GAE.  I tried this and ran into some CPU limits when
using it; admittedly, I did not pursue this option very far.  The CPU limits
were mostly due to the time that Crunchy would spend to transform/format a
static (html or rst) page into an interactive one.

3. Port Crunchy to a server owned by the PSF and running some version of GAE
to have slightly more generous CPU limits so that the proper processing
could be performed by Crunchy.  This might be feasible...  Users would just
log in (or use it anonymously) to try the tutorial.

4. Use Silverlight/Moonlight as mentioned by Michael Foord ... with the
caveats he mentioned.

5. Have a more basic tutorial that could be handled entirely by Skulpt (
http://www.skulpt.org/), a javascript based Python interpreter.

6. Use PyPy to create a sandboxed version of Crunchy that could run on a PSF
server.  I have never tried PyPy and do not know enough to comment further.

Still looking for a good working solution....

André  (Roberge)

<http://www.ironpythoninaction.com/>
>
>
> _______________________________________________
> pydotorg-www mailing list
> pydotorg-www at python.org
> http://mail.python.org/mailman/listinfo/pydotorg-www
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/pydotorg-www/attachments/20100421/792c6798/attachment.html>