Also geeky fun to try to recognize what constants like 4294967295 correspond to -- it's all over the place!
And lots of literal char* strings encoded as integer sequences:
>>> s = [111,98,106,101,99,116,46,95,95,102,111,114,109,97,116,95,95,32,119,105,116,104,32,97,32,110,111,110,45,101,109,112,116,121,32,102,111,114,109,97,116,32,115,116,114,105,110,103,32,105,115,32,100,101,112,114,101,99,97,116,101,100,0]
>>> ''.join(map(chr,s))
'object.__format__ with a non-empty format string is deprecated\x00'
It's an interesting proof of concept. I did a quick "benchmark" by calculating the 30th Fibonacci number with a dumb recursive implementation and there was a 60-70x difference in speed. I wonder how much of the speed difference is solvable and how easy it would be to have a DOM API.
If one is interested in doing this optimally, it should be better to compile python code to javascript directly. Given similarities between the language, it is a doable proposition. For some constructs, walking the python AST (which python so conveniently exposes) and translating the nodes to corresponding javascript should be quite direct. But a complete coverage of python will not be a trivial undertaking.
Oh wait! pyjamas does exactly that http://pyjs.org/ This is the first time I came to know about this project. So I have no experience with it whatsoever. [Well, that applies to my experience with javascript too.]
Edit: from a quick look it seems pyjamas will not give you a python REPL, I am not sure. But nevertheless this looks very interesting
> If one is interested in doing this optimally, it should be better to compile python code to javascript directly.
Well no, this is not possible, because python and javascript have very different semantics, notably regarding numeric types. You would have to enclose every python numeral in an object, and that in itself would already cripple the performance quite a bit. It would probably be less than the emscripten approach, but not by that much of a margin.
I started doing a python to lua compiler, and did hit that wall very fast.
Pyjamas python to javascript compiler is basically a toy regarding compliance to python spec. Every number is treated as a float, which means any numeric python library/function may not work correctly in pyjamas.
That's not the only difference in semantics between python and javascript. Just the most performance expensive.
Note that pyjs has several compilation options, one of which wraps numbers to distinguish between float and int. However, stuff like correct delegation with multiple inheritance might never work because js can only have one delegate. Currently one of the big problems in practice is that attribute access doesn't behave like getattr, which makes working with @property inconsistent. Also, __call__ doesn't work. Lots of minor details. At least they are checked in the unit tests, in case someone wants to help.
Hey, thanks for the precision, i didn't know you could box numbers in pyjs, i wonder how i missed that when i read the source. What is the typical performance hit from doing that ?
I really don't remember the exact numbers, anymore. A few times slower. The slowdown certainly is significant enough for number-crunching code, but end-users wouldn't notice the difference for simple calculations. I haven't yet played with per-module compilation flags, but it would be possible to compile performance-critical modules with a higher optimization level. Such a solution might require a little wrapper to convert between the data types, depending on the chosen compilation options, but it's the same when talking to raw JS code.
Long answer, it can run some parts of it if you join them (e.g., separating tokens, counting probabilities, some tagging and even some more advanced stuff). You cannot however, run everything (for exemple, modules and functions depending on NumPy) and must deal with how to import/export data.
http://syntensity.com/static/python.js
Also geeky fun to try to recognize what constants like 4294967295 correspond to -- it's all over the place!
And lots of literal char* strings encoded as integer sequences: