Python+Pyjamas+V8=ftw

[inhahe]

I don't know how much the community knows about this - i haven't been
participating much of late - but here's something amazing.

Apparently javascript is just as dynamic as python, because someone made a
python-to-javascript converter in just 1200 line (pyjamas). Meanwhile
google's new javascript engine (v8) blew all the others out the water,
raising the bar - and now safari and firefox already have already risen to
that bar with their own jit js engines.

The exciting thing is that python code converted to javascript runs on v8 10
times faster (http://www.advogato.org/article/985.html).

Thus google's strategy in making the JIT compiler represents what Python
could (and should) be. Python should either adapt v8, Tamarin
(http://en.wikipedia.org/wiki/Tamarin_(JavaScript_engine), or similar to
make its own JIT, or take their basic principles
(

) and recreate them for its own
JIT from scratch.

Until then, we can always install v8/tamarin/tracemonkey/squirrelfish and
easily make a front-end that automatically uses pyjamas to convert python
script to JS and runs it. Perhaps pyjamas needs some improvement to fully
implement Python - the homepage isn't very clear on how exactly the JS
implementation mirrors the Python implementation. Also I suppose it doesn't
support Python 3.0 and would have to be changed to support that.

 

[alex23]

Python should [...]

The problem with statements like this is that Python itself can't do
anything, only members of the Python community can.

But I do understand and agree with your main point. I'm hoping that
the PyPy project will allow for more rapid experimentation with new
JIT & VM techniques, with the more successful making their way into
the CPython VM over time. The project isn't quite at the point yet,
but they're still heading in that direction:
http://morepypy.blogspot.com/2008/10/sprint-discussions-jit-generator.html

Another project similar-ish to Pyjamas is HotRuby: http://hotruby.yukoba.jp/
However, it doesn't use the code-to-JS approach, rather it has
implemented the Ruby VM (or a subset thereof) in JavaScript and runs
Ruby bytecodes directly. Under Chrome, this results in a 16x increase
over the Ruby 1.9 VM.

It certainly looks like some interesting times are ahead for dynamic
languages:
http://steve-yegge.blogspot.com/2008/05/dynamic-languages-strike-back.html

 

[lkcl]

Another project similar-ish to Pyjamas is

HotRuby:http://hotruby.yukoba.jp/

also there's RubyJS:

http://rubyforge.org/projects/rubyjs/

it's again a javascript compiler - ruby to javascript - and the
beginnings of a port of GWT to Ruby, called rwt.

this project _definitely_ needs more attention.

michael's talk (included in the docs/) shows that he has spent
considerable effort in ensuring that not only is the compiler faithful
to the features of ruby, but also that the features are translated
_efficiently_.

which takes a hell of a lot of doing.

the nice thing about michael's work is that he's leading the way in
showing the pyjamas compiler how it _really_ should be done.

pyjamas is capable of running a very significant amount of python,
but it _is_ missing some crucial features: **kwargs for example, and
the 0.4 release has just added a _very_ basic type of exception
handling.

that having been said: for the majority of purposes - most web
development - pyjamas is _more_ than adequate.

as a general-purpose plugin replacement for /usr/bin/python, however,
it's not quite there. and, given that javascript cheerfully goes
about its way with the "undefined" concept, it's always going to be a
_bit_ tricky to provide absolutely _every_ language feature,
faithfully.

that having been said, the speedup factor of pyv8 should make the
pyjamas compiler a _really_ attractive option, and i think that when
it becomes the "norm" to have a javascript interpreter as part of a
sysadmin's / developer's dailiy life in the same way that /usr/bin/
perl
and /usr/bin/python are, then compilers like RubyJS, Pyjamas and GWT
will have a much bigger significance.

l.

 

[Kay Schluehr]

 as a general-purpose plugin replacement for /usr/bin/python, however,
it's not quite there.  and, given that javascript cheerfully goes
about its way with the "undefined" concept, it's always going to be a
_bit_ tricky to provide absolutely _every_ language feature,
faithfully.

For some reasons I'd do it the other way round and model JS entirely
in Python first. This is rather gratefully supported by two facts

1) Python is far more powerful than JS and supports lots of
metaprogramming facilities. For example providing a Python type that
has JS
prototype semantics isn't really a big deal.

2) JS is standardized and the standard is very well documented.

When JS has been mapped onto a dedicated Python framework one can open
the backchannel and translate the Python framework code to JS. Ideally
the mapping P_JS -> P_PyJS -> P'_JS is an identity. PyJS is
unambiguously fixed by this mapping.

Now people may define mappings from Python types to PyJS types and all
the checks and tests are performed as usual checks in Python code by
API functions of the PyJS framework. The compiler hasn't anything to
do with it anymore and can be somewhat liberated from hard work. This
roundtrip breaks with the GWT scheme of one way translation for an
obvious reasons: Python is not Java.

Regards, Kay