On May 18, 11:02 pm, Terry Reedy <tjre...@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. -- http://mail.python.org/mailman/listinfo/python-list
