pyjamas 0.8alpha1 release

[lkcl]

On May 18, 11:02 pm, Terry Reedy <tjre... at udel.edu> wrote:
> On 5/18/2011 5:24 AM, lkcl wrote:
>
> There seem to be two somewhat separate requirement issues: the
> interpreter binary and the language version.

 yes.  [with the startling possibility of compiling the entire pyjs
compiler into javascript and executing under e.g. spidermonkey's /usr/
bin/js turning that into just the one requirement - but that's another
story]

> >   a) at the moment ahttp://python.org2.N interpreter is required to
> > actually run the translator.  if you usehttp://python.org2.5 or 2.6
> > you do not need to use the "--internal-ast" option.  if you use 2.4,
> > 2.7 or above, you will need to use --internal-ast because we're
> > heavily reliant on the internal c-based "compile" module [without the
> > --internal-ast option enabled].
>
> I presume '--internal-ast' is a 'compile the interpreter' option.

 mmm... sort of.  what it does is, in translator.py (the pyjs python-
to-javascript compiler) is this:

 if options.internal_ast:
     import pyjamas.pgen.compile as compile # python version of
compile module
 else:
     import compile # standard python compile module

 that "internal" compile module contains a complete independent
grammar.txt file, and is basically lib2to3 re-ported *back* to being
interoperable with, and a complete replacement for, the standard
python "compile" module.  including the ast module.

 we haven't *quite* got round to doing a "compile the interpreter" yet
- it's half way there.  the work that daniel kluev is doing, for his
gsoc2011 project, will be a complete "compile the interpreter".

 by the time he's done, we'll even have "eval()" and "exec()"
builtins... inside a web browser.

> Since
> I have never compilied Python (or anything else for perhaps 15 years), I
> do not understand completely. Am I correct to guess that the PSF Windows
> binaries for 2.7 were not compiled with the flag, and will not work? If
> so, Windows users should, I would think, use the latest 2.6.6 binaries.

 ahh... i'm reading this as "requiring http://python.org c code to be
compiled with different compilation flags".  this isn't anything to do
with compiling c-code: "pyjs the translator" is and always will be a
pure vanilla python application, requiring absolutely no modifications
to the python interpreter whatsoever.

 the --internal-ast option is an option which is passed to the pyjs
application (which is a pure and vanilla python application).  here's
an example, shows the inter-relationships:

 /usr/bin/python pyjsbuild.py --internal-ast Hello.py
 python.exe pyjsbuild.py --internal-ast Hello.py

 * /usr/bin/python or python.exe - python2.N.

 * pyjsbuild.py - the pyjs python-to-javascript translator

 * --internal-ast - an option to pyjsbuild to tell it to use a version
of compiler.ast which is written in pure python [and supports the 2.6
grammar]

 * Hello.py - the pyjamas application, written in python, being
translated to javascript, for execution in a web browser.


> >   b) the actual pyjs interpreter grammar (AST) was 2.5 but has mostly
> > been updated to 2.6.  actual python syntax / features are therefore
> > mostly 2.5, with someone having pointed out that "slice" has different
> > return results it's hard to say exactly which is best to be picked,
> > 2.5 or 2.6.  nobody's needed slice until recently, so it's not an
> > issue that's ever come up before.
>
> If I understand this, the safe thing to do is to stick with 2.5 syntax
> and omit exotic 3.x features put into 2.6 for eventual porting to 3.x.

 yes.  that would be the easiest path.  however, we have a teeny
problem: pyjamas desktop (pyjd).  that's where you get to *really*
execute the python code, exactly the same code that you munged through
the pyjs compiler.  in the pyjd case, what is going on is that it is
*python* that has access to the features of the web browser engine
(DOM functions, HTML5 etc.) and that is... ho hum, each engine is
itself a massive project, and has to be a python c module (except for
the MSHTML engine, which is COM).

 so for pyjd, we *have* to support whatever the latest easiest python
2.N is.  that in turn dictates that we have to keep up-to-date with
the python 2.N syntax/grammar, and, consequently, it dictates
logically that the pyjs compiler, which *must* be interoperable with
pyjd, must also support the latest python 2.N syntax/grammar.

 bummer, huh? :)

 fortunately, nobody on the pyjamas mailing list has really noticed
that there _are_ any differences (!) between 2.5, 6 and 7 - except for
daniel kluev, the gsoc2011 student, who is using pyjs with python-pyv8
to actually create a version of a python interpreter... by translating
everything to javascript!

 the reason why they haven't really noticed is because the use-case
for pyjamas UI code is much much smaller (due to web browsers being a
restricted execution environment - see ongoing discussion below).

> >   the thing is - it's worth reiterating: you just... really don't need
> > as much python interoperability for user-interfaces when they're split
> > along MVC lines.  bear in mind that it's necessary to do that split:
> > it's web browser technology, you can't *actually* execute things like
> > psycopg or mysql in a web browser as javascript!  so once you've
> > divided that application into "python that runs the actual user
> > interface" and "python on the other side of the AJAX barrier e.g. a
> > django app" you're left with a far smaller task for the pyjs
> > interpreter to have to tackle.
>
> I do not get all this but it seems to say that I do not really need all
> the features of the later Pythons to write user-interface code.

 by a roundabout route... yes.  it's due to web browsers being a
massively restricted environment.

> But I am
> not sure how this applies to business code behind the front end. Of
> course, it might work to run the UI in a separate process if on the same
> machine.

 ok, that's basically what happens: it's not like there is any choice
in the matter.  the python UI code has been translated to javascript:
it's now an AJAX application, not a python application.  the UI code
therefore runs in that browser's "separate process".  it's a highly
restricted execution environment that's very very well-defined, and
you cannot, *cannot* in any way go outside of the boundaries, as
defined by W3C (sort-of).

 the only access to the outside world is either AJAX, HTML5 Sockets
(if supported), or for the user to agree to the installation of a
plugin (such as silverlight, java, adobe flash, or god forbid the
xulrunner / firefox "language=python" extension which was sponsored by
the mozilla foundation back in 2000 - it quite literally embeds the
entire libpython library into a firefox plugin!)

 so, you REALLY have to subdivide the application, just as you have to
subdivide *any* AJAX application, into "front-end", "back-end".  at
the front-end, you can do anything... as long as it's restricted
javascript; at the back-end (server-side) you can do ANYTHING.
django, whatever - even php or .net if you're feeling sick...

 this does take quite a long time to sink in :)  even i had difficulty
appreciating that yes, you can write UI web applications *in python*,
but nooo, you can't *actually* execute that python code in the web
browser, and consequently nooo, you cannot have "standard" python
modules in the web browser.

 it's kinda like pypy - you can have anything you like, as long as
it's in pure python [so it can be translated to javascript].

l.