Summer of Code Project Idea: Python Apps in the Browser
The http://gumbyapp.com/ project succeeded in getting Python to run in the browser but it can't import pure python modules (because there is no filesystem in the browser). I think it would be wonderful to beef-up this project by bundling-in the rest of the standard library. Gumby was built by compiling CPython to LLVM and then generating Javascript. ISTM it would be possible to write a script to transform pure python standard library modules into C strings that could also be part of the final build. The import-statement would have to be hooked to search for the C string instead of a physical file. If that technique works, it may not be hard to extend it so that user defined python modules could also be incorporated. If so, it would become possible to create standalone Python apps that run in the browser. The process is likely to be inefficient, but the gumbyapp site shows that it might be good enough for some purposes. Raymond
Or maybe a URL importer that is restricted to same domain http://code.google.com/p/importers/issues/detail?id=1
On 25 August 2011 23:45, Raymond Hettinger <raymond.hettinger@gmail.com>wrote:
There's also Skulpt, an implementation of Python in Javascript (no idea how complete it is but I saw some impressive demos a while ago): http://code.google.com/p/skulpt/ I've no idea how skulpt handles imports (or even if it does). There is also pyjamas which translates Python code to Javascript: http://pyjs.org/ Pyjamas translates dependencies too, but I guess it can't do dynamic imports. Plus IronPython runs in the Silverlight runtime. Probably of less interest to this crowd though. :-) All the best, Michael Foord
-- http://www.voidspace.org.uk/ May you do good and not evil May you find forgiveness for yourself and forgive others May you share freely, never taking more than you give. -- the sqlite blessing http://www.sqlite.org/different.html
On Fri, Aug 26, 2011 at 11:11 AM, Michael Foord <fuzzyman@gmail.com> wrote:
Plus IronPython runs in the Silverlight runtime. Probably of less interest to this crowd though. :-)
In the talk at PyConAU that mentioned gumbyapp [1], trypython was the first version Tim showed. Gumbyapp was his follow-up for the cases where Silverlight wasn't an option (or ran too slowly). Although it turns out many browsers aren't happy about being sent 2.8 MB JSON objects, either :) It's actually a really cool talk (and my personal favourite of the whole weekend at PyConAU) about how the National Computer Science School run by the University of Sydney uses OS level sandboxing to permit safe execution of arbitrary Python code on the NCSS servers (alas, UoS has not made the code backing the site open source at this point in time and Tim wasn't sure if or when that would happen). To add another possible mechanism into the mix, freezing modules may be another way to get them into the LLVM bytecode. Dynamic import mechanisms are hard, since you run into bootstrapping issues (cf. Brett's hassles with making importlib the underlying implementation of the __import__ builtin). [1] http://www.youtube.com/watch?v=y-WPPdhTKBU&feature=channel_video_title Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia
On 26 August 2011 03:28, Nick Coghlan <ncoghlan@gmail.com> wrote:
Interesting. Last year I wrote a commercial app with a Silverlight front-end (choice of the client) where we were sending 10mb or more of json over the wire (per view). We found IronPython in Silverlight *much faster* than Javascript, both for json handling (using the Silverlight json apis) and for the user interface, which was a grid displaying the large amounts of data we were sending. (I was porting a Javascript app to Silverlight and performance was one of the big reasons.) My understanding is that even with recent javascript engines the Silverlight runtime *typically* runs code faster than Javascript. As gumbyapp is translating llvm bytecode to Javascript I'd be *surprised* if it was faster than Silverlight (not that aren't other reasons to prefer a 'browser native' solution though). Just because I'd be surprised doesn't make it impossible of course. :-) All the best, Michael Foord
-- http://www.voidspace.org.uk/ May you do good and not evil May you find forgiveness for yourself and forgive others May you share freely, never taking more than you give. -- the sqlite blessing http://www.sqlite.org/different.html
On 26 August 2011 03:28, Nick Coghlan <ncoghlan@gmail.com> wrote:
Ooh, nice. Here's the "Try Python" variant they created for the students / teachers to run Python, with an interactive interpreter and editor: http://challenge.ncss.edu.au/trypython/ Thanks for pointing this out. (Try Python provides a "filesystem" based on browser local storage and patches "open" to work with this. Adding an import hook that can import from the browser filesystem wouldn't be very hard and it looks like they have *something* like that in place.) All the best, Michael Foord
-- http://www.voidspace.org.uk/ May you do good and not evil May you find forgiveness for yourself and forgive others May you share freely, never taking more than you give. -- the sqlite blessing http://www.sqlite.org/different.html
On 8/25/11 3:45 PM, Raymond Hettinger wrote:
[1] http://davisagli.com/blog/the-making-of-zodb.ws [2] https://github.com/kripken/emscripten/wiki Our goal was getting ZODB running in the browser, with storage in HTML5 localstorage, as demonstrated at http://zodb.ws -- so we focused only on the pieces of the stdlib necessary to get that running; the emscripten interpreter was missing a lot and we didn't have time to learn the emscripten toolchain so we resorted to various hacks (e.g. a simple incrementer in place of time.time()) and borrowing pure-Python implementations from pypy. David
Or maybe a URL importer that is restricted to same domain http://code.google.com/p/importers/issues/detail?id=1
On 25 August 2011 23:45, Raymond Hettinger <raymond.hettinger@gmail.com>wrote:
There's also Skulpt, an implementation of Python in Javascript (no idea how complete it is but I saw some impressive demos a while ago): http://code.google.com/p/skulpt/ I've no idea how skulpt handles imports (or even if it does). There is also pyjamas which translates Python code to Javascript: http://pyjs.org/ Pyjamas translates dependencies too, but I guess it can't do dynamic imports. Plus IronPython runs in the Silverlight runtime. Probably of less interest to this crowd though. :-) All the best, Michael Foord
-- http://www.voidspace.org.uk/ May you do good and not evil May you find forgiveness for yourself and forgive others May you share freely, never taking more than you give. -- the sqlite blessing http://www.sqlite.org/different.html
On Fri, Aug 26, 2011 at 11:11 AM, Michael Foord <fuzzyman@gmail.com> wrote:
Plus IronPython runs in the Silverlight runtime. Probably of less interest to this crowd though. :-)
In the talk at PyConAU that mentioned gumbyapp [1], trypython was the first version Tim showed. Gumbyapp was his follow-up for the cases where Silverlight wasn't an option (or ran too slowly). Although it turns out many browsers aren't happy about being sent 2.8 MB JSON objects, either :) It's actually a really cool talk (and my personal favourite of the whole weekend at PyConAU) about how the National Computer Science School run by the University of Sydney uses OS level sandboxing to permit safe execution of arbitrary Python code on the NCSS servers (alas, UoS has not made the code backing the site open source at this point in time and Tim wasn't sure if or when that would happen). To add another possible mechanism into the mix, freezing modules may be another way to get them into the LLVM bytecode. Dynamic import mechanisms are hard, since you run into bootstrapping issues (cf. Brett's hassles with making importlib the underlying implementation of the __import__ builtin). [1] http://www.youtube.com/watch?v=y-WPPdhTKBU&feature=channel_video_title Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia
On 26 August 2011 03:28, Nick Coghlan <ncoghlan@gmail.com> wrote:
Interesting. Last year I wrote a commercial app with a Silverlight front-end (choice of the client) where we were sending 10mb or more of json over the wire (per view). We found IronPython in Silverlight *much faster* than Javascript, both for json handling (using the Silverlight json apis) and for the user interface, which was a grid displaying the large amounts of data we were sending. (I was porting a Javascript app to Silverlight and performance was one of the big reasons.) My understanding is that even with recent javascript engines the Silverlight runtime *typically* runs code faster than Javascript. As gumbyapp is translating llvm bytecode to Javascript I'd be *surprised* if it was faster than Silverlight (not that aren't other reasons to prefer a 'browser native' solution though). Just because I'd be surprised doesn't make it impossible of course. :-) All the best, Michael Foord
-- http://www.voidspace.org.uk/ May you do good and not evil May you find forgiveness for yourself and forgive others May you share freely, never taking more than you give. -- the sqlite blessing http://www.sqlite.org/different.html
On 26 August 2011 03:28, Nick Coghlan <ncoghlan@gmail.com> wrote:
Ooh, nice. Here's the "Try Python" variant they created for the students / teachers to run Python, with an interactive interpreter and editor: http://challenge.ncss.edu.au/trypython/ Thanks for pointing this out. (Try Python provides a "filesystem" based on browser local storage and patches "open" to work with this. Adding an import hook that can import from the browser filesystem wouldn't be very hard and it looks like they have *something* like that in place.) All the best, Michael Foord
-- http://www.voidspace.org.uk/ May you do good and not evil May you find forgiveness for yourself and forgive others May you share freely, never taking more than you give. -- the sqlite blessing http://www.sqlite.org/different.html
On 8/25/11 3:45 PM, Raymond Hettinger wrote:
[1] http://davisagli.com/blog/the-making-of-zodb.ws [2] https://github.com/kripken/emscripten/wiki Our goal was getting ZODB running in the browser, with storage in HTML5 localstorage, as demonstrated at http://zodb.ws -- so we focused only on the pieces of the stdlib necessary to get that running; the emscripten interpreter was missing a lot and we didn't have time to learn the emscripten toolchain so we resorted to various hacks (e.g. a simple incrementer in place of time.time()) and borrowing pure-Python implementations from pypy. David
participants (6)
-
David Glick -
Dj Gilcrease -
Guido van Rossum -
Michael Foord -
Nick Coghlan -
Raymond Hettinger