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.)"
Because it's done like this:
<?php
die(Python);
?>
signature is pants
I'd be interested to hear what you like better, and why? Personally I'm still sad that Java (not Javascript) didn't win on the Web - a cross-platform, general purpose language that is at least a reasonable choice for most anything. To make programming faster, you can always use higher-level libraries or code-building environments on top of it, or compile some other syntax to java bytecode.
Now instead the Web is a big mish-mash of fundamentally incompatible technologies. And if anybody does pull off the one-runtime-for-anything vision, it looks like it will be Microsoft.
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.
As a high school computer science teacher, I can see a practical application of this. Currently, I think Python is one of the best languages to learn basic programming concepts with, in that it is relatively straightforward, powerful, and there's not much "voodoo" to prevent students from diving right into programming. It's possible to do some really cool things in Python with not much code.
However, one of the problems is that it can be difficult to give students a way to show off their code. Since it's an interpreted language, they can't just give an .exe or a .app file to someone else to show it off - they need to say, "Oh, go and install Python, and these libraries, etc." Yes, there are solutions such as py2exe and py2app, but getting these set up can be quite a task in itself. By running Python inside JavaScript, you basically open up the whole web-connected world as a potential audience to these budding programmers. It's much easier to say, "Hey, check out this link!" than "Hey, download Python (but get the right version) and this graphics library, then download my .py file, and open up a command prompt and type python blahblah.py!"
Cleaning up the browser programming environment is not about getting rid of Javascript.
Maybe not, but javascript is not a good language, it's a bad language with some good features. The awful scoping mechanism is evidence of this enough. The intrinsic objects are too limited to be useful, so much so that now there are more than 4 different common framework projects to handle all the inconsistency in implementation and they're all incompatible with each other. anonymous functions are great but they make debugging a giant pain the arse.
i would like to see a viable alternative language to javascript, just for variety's sake. It's just had layers of crap pasted on top of it since 1995 or whatever and it'd be nice to see a new approach that fits what people actually use it for these days.
This comment is fully compliant with RFC 527.
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.
...they used a Perl script to convert Python to Javascript.
Found something better: 6502 assembler!
I felt the same way until I watched Douglas Crockford's videos on javascript. If you hate javascript, you're doing it wrong. I now prefer it to the other languages being discussed here.
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
i know you're joking, but there really _is_ a Visual Studio "universal translator" plugin available - i've seen it demo'd, converting c++ to java, to B, to ruby, to c#. it all used CLR as the intermediary. i heard that activestate were commissioned to add python to the mix, but, weirdly, it wasn't included in the release of the translator i saw.
Python is quite a good language, but the implementations suck. This is holding back widespread use of Python. It's too slow, typically 10x to 30x slower than C. That's far worse than Java.
There have been several attempts at other implementations. But because Guido Rossum fights formal standardization of the language, treating his CPython implementation as a de-facto standard, everyone else has a moving target to hit.
Google (who hired Guido) likes Python, but they don't like the low performance. CPython is a "naive interpreter" (very little optimization). Worse, with the rather lame implementation the Global Interpreter Lock, not only can't it use a multi-core CPU effectively, multi-thread programs run slower on multi-core CPUs. (The threads fight over the lock in an embarrassingly inefficient way.)
Google is doing "Unladen Swallow", which is an attempt to bolt CPython to a just-in-time compiler to a virtual machine. It's not clear how well that will work out, but the end result will have more layers than seems to be indicated. The goal is 5x faster than CPython, which won't beat Java, let alone C/C++.
It's cute that Python to JavaScript translation is possible, but it's not going to help much on the performance front.
For a few years, the great hope of the Python community was PyPy, but that had too many goals, was being developed in "sprints", and after five years, the European Union pulled the plug on funding after it was slower than CPython.
Shed Skin, which is a Python to C++ hard-code compiler, is currently the lead in Python performance, but it doesn't yet implement the whole language. Still, with about two people working on it, Shed Skin is doing better than most of the bigger projects. Shed Skin does automatic type inference. Python doesn't have declarations, but with enough analysis, the compiler can figure out what types each variable can hold and generate hard types, which makes for much faster code.
Because it IS easier to use and hardware is always getting cheaper.
On the server side, 10x to 30x slower means building entire buildings full of servers. Or more expensive hardware in the cell phone. Or using another language.
Python is actually a good general-purpose programming language, not just a "scripting language". The big problem is slow execution.
The basic problem with CPython is that, being a naive interpreter, it has to check for the hard cases every time. "n = n + 1" ought to be a few machine instructions, maybe only one. But Python has to check for n being a float, n being a string, n being an object, etc., every time. Shed Skin, with a type inference systems, does analysis at compile time and determines that n is always an integer, then generates code for integer arithmetic only.
There are all sorts of dynamic things one can do to a Python program while it's running. You can add a function to an object. You can replace existing functions. You can load new modules on the fly. But most of the time, for most of the objects, you don't do that. An efficient implementation needs to separate out the cases where something unusual might occur, and the far more common cases when the program is doing routine stuff that needs to go fast. The common cases can then be handled with much simpler, and faster, code.