Python Converted To JavaScript, Executed In-Browser
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.)"
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
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.
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.
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 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.
Verbum caro factum est