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
--
http://mail.python.org/mailman/listinfo/python-list
