Python Converted To JavaScript, Executed In-Browser 176
lkcl writes "Two independent projects, Skulpt and Pyjamas, are working to bring Python to the web browser (and the JavaScript command-line) the hard way: as JavaScript. Skulpt already has a cool Python prompt demo on its homepage; Pyjamas has a gwtcanvas demo port and a GChart 2.6 demo port. Using the 64-bit version of Google v8 and PyV8, Pyjamas has just recently and successfully run its Python regression tests, converted to JavaScript, at the command-line. (Note: don't try any of the above SVG demos with FF2 or IE6; they will suck.)"
AS IF (Score:1, Informative)
Using python to GENERATE JavaScript, not python converted
Re:GWT for Python? (Score:4, Informative)
you're looking for RubyJS [rubyforge.org]. sadly, funding has not been forthcoming in order to carry RubyJS forward. the compiler is excellent; the insights into the technical issues behind dynamic language translation were very useful (even to python translator developers) - but martin ran out of time/money/enthusiasm due to the lack of interest shown, so he only got as far as creating HTML and Button for RWT (Ruby Web Toolkit).
Re:Pointless (Score:4, Informative)
There is already a Ruby VM that runs in a browser: Hotruby : http://hotruby.yukoba.jp/ [yukoba.jp]
John Resig even blogged about it ages ago: http://ejohn.org/blog/ruby-vm-in-javascript/ [ejohn.org]
Also, JS.class, while not a Ruby VM, is pretty cool and actually useful: http://blog.jcoglan.com/2009/06/08/jsclass-21-an-improved-pacakge-manager-proper-hashes-and-lots-of-ruby-19-goodness/ [jcoglan.com] - http://ajaxian.com/archives/jsclass-21-released [ajaxian.com]
Re:Now I've heard everything (Score:5, Informative)
Just when you thought things could not get any crazier, there's this story. Let's hope it's an early April Fool.
nope. it's not. and i didn't mention in the article that pyjamas-desktop can run the python as a desktop app, either. including the GWT Canvas ported code, under the MSHTML engine. after all, the IE/MSHTML gwtcanvas is just creating VML nodes, so perhaps it shouldn't come as a surprise that it works, but it's still pretty cool all the same.
There's no way one could simulate more than about 12% of Python's complex OO semantics in JavaScript.
wrong. sorry. javascript is a drastically underestimated language. dreadful to work with if you don't know what you're doing, but incredibly powerful at the same time.
a javascript implementation of "type" - not the 1-arg version but the full 3-arg version - was initially implemented in 85 lines of javascript (it's a bit more, now).
we use that functionality to dynamically create, classes, supporting multiple inheritance and more.
pyjamas has also implemented decorators _and_ properties; kees is currently working on "yield" after skulpt's developers started working on it. not "yield by cheating and using FF built-in support for yield", but "yield" as in doing it the hard way, by analysing the state of the function and adjusting / jumping to the correct point in the function on each loop.
you really should take a look at the regression tests [pyjs.org]
Python itself already has a hard and slow slog trying to perform all its tricks.
To add yet another layer of translation or simulation sounds like a lose-lose proposition. Slower and hopelessly inexact.
slower, yes - "hopelessly" inexact: no. for GUI purposes, _if_ you've designed the application correctly (i.e. along MVC / client-server lines), then the "-O" option which switches off all the python "strict" compatibility, is perfectly sufficient.
so, "letting things fall through" to javascript, and allowing int(width) + "px" to succeed, and [1,2,3] + [4] to fail, is "good enough for most purposes".
Not to mention many of the more useful Python modules have a considerable C component, making them completely unusable as JavaScript.
wrong again. sorry. two reasons. three.
1) pygtkweb showed that it is perfectly possible to make a seamless / transparent JSONRPC service that ships function call arguments over to a server, for execution server-side, starting from e.g. "import md5"
2) pyjamas' implementations of datetime, md5, urllib, time and a few others is growing as users contribute to them. thus, the pyjamas GUI library fits the *users* needs, on an ongoing basis.
3) if you _really_ can't do without the full semantics of python, but want the benefits of full HTML, CSS, NPAPI plugins etc., use one of the pyjamas-desktop ports. there's MSHTML, XULRunner and PyWebkitGTK to choose from.
Re:iPhone application? (Score:4, Informative)
I have an iPod touch running iPhone OS 3.1.1, so I tried these two projects out.
Skulpt works, but the console does not (I had to use the quick-links to test code). This is relatively easy to fix by using a textbox instead of using keyboard events. It would be very simple to write a simple webapp which evaluates Python code in the Safari browser. However, as I see it, Skulpt is still quite immature -- it doesn't implement much of the language (e.g. classes work, but can't be instantiated because Skulpt thinks you are trying to call the type object, instead of constructing it), and it doesn't do imports at all.
Pyjamas works extremely well, though it is compiled as pure JS and thus lacks (AFAIK) an "exec" method to run arbitrary Python code.
Given that Skulpt features a decent Python parser but lacks much of the core functionality, and Pyjamas implements a lot of functionality but lacks a parser built in JS, I think the projects would be mutually beneficial.
Re:GWT for Python? (Score:1, Informative)
It has been abused for years, and as such ignorant people have the opinion that it's just a toy language, when really it's incredibly powerful. You don't need a framework or a translator to write JS, same as you don't need one to write C. Learn the language, and you'll see it's not hard to program complicated stuff in it.
Look at Ext.js, Processing.js, and YUI, and tell me JS is "just way too stupid to program manually".
Re:iPhone application? (Score:5, Informative)
Pyjamas works extremely well, though it is compiled as pure JS and thus lacks (AFAIK) an "exec" method to run arbitrary Python code.
i'm working on it. last week i back-ported skulpt's parser and AST code from javascript to python, and regression-tested it; now it's a matter of improving the pyjamas compiler to be able to successfully compile that python into javascript, and we're bootstrapped.
Re:iPhone application? (Score:3, Informative)
there are a ton of different ways, now: i've been maintaining a list on the python wiki, WebBrowserProgramming [python.org] page. pypy used to have a -to-javascript back-end (now abandoned); there's titanium appcelerator (which supports IronRuby and IronPython); there's PyXPCOMExt and a few more besides.
Re:How about a Javascript - to - python convertor? (Score:4, Informative)
The link to Douglas Crockford's site in the parent was to an article entitled "The World's Most Misunderstood Programming Language".
The awful scoping mechanism
From the brief survey of Javascript [crockford.com] on Crockford's site:
"""
When used inside of a function, var defines variables with function-scope. The vars are not accessible from outside of the function. There is no other granularity of scope in JavaScript. In particular, there is no block-scope.
"""
iow, use the var keyword. Programmers who do not know this ONE RULE (TM) are bitten by mysterious insects. Use a lint program if needed.
Functions are objects in Javascript, so this effectively allows, in either functional or object styles of programming, programmers to freely and simply define their variable scoping.
Procedural programmers used to simple block scoping (Hi COBOL fans!) may need to find a mechanism to cope with this. But I'd suggest using OO techniques if your program is complex enough that this is a problem. Javascript allows simple, non-demanding OO. If you like your OO authoritarian then Google has a Java-to-javascript translator.
intrinsic objects are too limited to be useful, so much so that now there are more than 4 different common framework projects
Python has one official library (and many 'unofficial' modules too), without which Python would be very limited. Javascript has many unofficial libraries. Welcome to the free world.
btw, I use Python, and I get Twisted Python at least to some extent. Twisted's deferred abstraction is mimicked in Dojo Javascript. I use Python on the server and Javascript + Dojo on the browser. Python has less warts and more modules. Javascript has astounding power in simplicity, as in the scoping rule.
Re:Why don't browsers just support it? (Score:3, Informative)
That'd be damn hard. Python isn't made for sandboxing (google python and sandboxing, or restricted execution, and you'll see). If you did the script language=python implementation the "obvbious" way and just linked in the python interpreter into mozilla, you'd have a security hole big enough for a supertanker. There is Python support for extensions though - google PyXPCOM.
Re:Python implementations still suck (Score:3, Informative)
Don't use threads. Use multiprocessing for concurrency and Twisted for asynchronous I/O.
If you're going to complain about the GIL, perhaps you should go read up on why it's necessary, and perhaps share some of your amazing insights on a better, more performant way to do threading.
PyPy is far from dead. They've got a JIT working for x86 assembly that matches NumPy in some tests.
Re:Python implementations still suck (Score:3, Informative)
I used to have the idea that Java was inherently slow. It is not. Some implementations of the Java libraries are slow, Swing is a bit sluggish on some platforms (it is largely coded in Java rather than using native toolkit functionality) but the Java language itself is quite fast. If coded well, you can get performance comparable to C, but that is also quite dependent on how well your virtual machine JIT compiles the code (or, if it does).
I'm sure a lot of people base their preconceptions of Java being slow on programs like Azureus and Eclipse. These programs are slow because they are big and bloated, not just because they are coded in Java. On GNU/Linux systems especially (older Ubuntu releases were bad for this), the packages distributed in the repository would run use GCJ even when the much more efficient Sun runtime was installed.
I'm not a Java fanatic, nor an IBM troll. /p.