pyjamas 0.8alpha1 release

[Terry Reedy]

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.

>   a) at the moment a http://python.org 2.N interpreter is required to
> actually run the translator.  if you use http://python.org 2.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. 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.

>   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.

>   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. 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.

>>>    otherwise please - really: just saying "give me support for python
>>> 3.x or else" is ...
>>
>> And I did not say that.
>
>   yeah i know - i'm sorry: it just, with a little bit of "twisting",
> could be construed as implying that.

Let me be clear: some people think that free (as in beer) software 
developers have some sort of one-sided responsibility or obligation to 
users who pay nothing. I don't. If I say "Give me a Python 3 version of 
pyjamas or I will not use it", I consider you free to respond "Fine, 
don't use it." End of story until I compromise or contribute. I feel 
free to say the same to anyone who says "Stop developing new versions of 
Python or I will quit using the current version".

>   :)  i think... people forget that there are now two mutually-
> exclusively-incompatible programming languages out there, where the
> first six letters of the name of the programming language happen to be
> the same...

Something of an exaggeration. It might well be possible to use a 3to2 
frontend and run a mildly restricted subset of 3.x.

-- 
Terry Jan Reedy