FAQ
after a long delay the pyjamas project - http://pyjs.org - has begun the
0.8 series of releases, beginning with alpha1:

https://sourceforge.net/projects/pyjamas/files/pyjamas/0.8/

pyjamas is a suite of projects, including a python-to-javascript
compiler with two modes of operation (roughly classified as "python
strict" and "Optimised"); a GUI Framework almost identical to that of
the GWT Project (1.5 to 1.7); and a "Desktop" version which is similar
in concept to Adobe Air, allowing python applications to be run -
unmodified - as stand-alone Desktop Applications. pyjamas can
therefore be considered to be a Desktop GUI framework - a peer of GTK2
and QT4 - with the startling capability that applications can also be
compiled to javascript and run in any modern web browser with
absolutely no special plugins required, or it can be considered to be
an AJAX Web Framework with the massive advantage that applications are
written in python (not javascript) with a "Desktop" mode as well.
both descriptions are accurate, making pyjamas the world's only free
software python-based platform-independent, browser-independent,
GUI-toolkit-independent and OS-independent "Holy Grail" GUI
development environment [so there. nyer, nyer to the corporate big
boys with access to $m who *still* haven't managed that one]

also included are ports of GChart and GWTCanvas, each of which run
under all web browsers and all desktop engines (with the exception at
present of the python-webkit desktop engines, which presently do not
support SVG Canvas). all pyjamas UI libraries are designed to be
browser-independent as well as platform independent. the usual
"browser foibles", tricks and gotchas are catered for with a
transparent "Platform Override" mechanism which ensures that the
published API of each UI Library is identical across all platforms
(including the Desktop Engines). [no more "If Platform == IE or
Platform == Opera...."]

due to the sheer number of modern browsers as well as the number of
pyjamas-desktop engines required to be supported, the 0.8 series will
be ready declared "stable" when sufficient community-led testing has
been done. bugreports are in for Opera 11, IE8 and Google Chrome:
http://code.google.com/p/pyjamas/issues/detail?id`0
http://code.google.com/p/pyjamas/issues/detail?id`1
http://code.google.com/p/pyjamas/issues/detail?idY7

still requiring testing and confirmation is Opera 9 and 10; Firefox 2,
3, 3.1, 3.5, 3.6 and 4.0; IE6, 7 and 9; Safari 3 and 4, as well as
mobile phone browsers Android, Symbian Series 60, iphone, ipad and
blackberry OS 4. also requiring testing and confirmation is the
Desktop Engines, of which there are now four variants: XulRunner
(Firefox Engine), pywebkitgtk, MSHTML and the new addition pywebkitdfb
(DirectFB). each browser and each engine requires each of the 70
examples to be run, and in the case of the pyjamas compiler (pyjs),
compilation is required with both -O and --strict (with the exception
of the LibTest example).

the pywebkitdfb engine is a new addition, and merits a particular
mention. some time last year, both GTK2 and QT4 independently
announced that they were dropping support for DirectFB from future
versions, and Enlightenment had not tested the DirectFB port for some
considerable time. Webkit-GTK with the older GTK-DirectFB libraries
simply would not compile. in the embedded space, where it can take 30
seconds to fire up Webkit-GTK on a 400mhz ARM9 and even longer to
start up WebkitQT4, this was something of a disaster. To fix this, a
new port of Webkit was created which uses DirectFB directly, using a
tiny 50k Widget Toolkit called "Lite". This development coincided
with the re-engineering of pywebkitgtk and the creation of the
pythonwebkit project, http://www.gnu.org/software/pythonwebkit:
pywebkitdfb was therefore also created at the same time.

Cutting a long story short, pywebkitdfb now exists and has a startup
time on 400mhz ARM9 processors of under 1.5 seconds. The startup time
of both WebkitDFB and pywebkitdfb on Dual-Core 2ghz Intel systems is
so quick that it's difficult to determine: an estimate is under 0.1
seconds (100ms). WebkitGTK. WebkitEFL and WebkitQT4 have
approximately 20 times or longer startup times. So although WebkitDFB
is still significantly experimental, it is definitely worthwhile
considering, especially for Embedded Systems, but even for use on
X-Windows, and even just as a plain (but modern) web browser for those
people sick to the back teeth of long startup times on their web
browser [and it has python bindings, too. yaay!]

summary: developing applications in pyjamas means the application can
be made to run just about anywhere, and it's an entirely python-based
and a free software framework. it's a community-driven project, so
requires *your* input to get it to a proven stable state.

http://pyjs.org

Search Discussions

  • Luke Kenneth Casson Leighton at May 4, 2011 at 3:53 pm

    On Wed, May 4, 2011 at 3:06 PM, Luke Kenneth Casson Leighton wrote:

    after a long delay the pyjamas project - http://pyjs.org - has begun the
    0.8 series of releases, beginning with alpha1:

    https://sourceforge.net/projects/pyjamas/files/pyjamas/0.8/

    pyjamas is a suite of projects, including a python-to-javascript
    compiler with two modes of operation (roughly classified as "python
    strict" and "Optimised"); a GUI Framework almost identical to that of
    the GWT Project (1.5 to 1.7);
    oh one other thing - for the 0.8 release, jim washington kindly added
    an HTML5-compliant "Drag-n-Drop" interface, which, on web engines that
    do not have HTML5, is emulated. and thus provides the exact same API,
    regardless of the web browser being used. cool, huh? if i was a
    java-lover, i'd look forward to that being added some day to GWT.

    btw - if anyone's at all curious [about GWT "Desktop" possibilities],
    there *does* exist a sort-of "Desktop" version [not really] - it's
    basically webkit, it requires execution under the eclipse IDE, and
    it's still javascript (not Java). i _did_ speak to the GWT Team,
    raising with them the possibility of doing Java bindings to Webkit [or
    XulRunner, or MSHTML] and providing a port of GWT that can run GWT
    applications REALLY as stand-alone Desktop applications, and they
    basically implied that that'll happen "when hell freezes over". i
    guess the idea of providing languages other than javascript with
    direct access to the full and incredible capabilities of DOM and HTML5
    is just... too alien. which is funny, because pyjamas desktop shows
    what can be done: web browser engines can literally be turned into
    cross-platform GUI engines.

    l.
  • Terry Reedy at May 4, 2011 at 6:37 pm

    On 5/4/2011 10:06 AM, Luke Kenneth Casson Leighton wrote:
    after a long delay the pyjamas project - http://pyjs.org - has begun the
    0.8 series of releases, beginning with alpha1:

    https://sourceforge.net/projects/pyjamas/files/pyjamas/0.8/

    pyjamas is a suite of projects, including a python-to-javascript
    compiler
    As you well know, there is no such thing as 'python' when it comes to
    compiling actual code. So please specify both in announcements here and
    on the project homepage http://sourceforge.net/projects/pyjamas/
    which versions are supported. I do not really want to have to download
    and experiment to determine whether to bother downloading.

    If you do not yet support 3.x, I request and recommend that you do so,
    even if only on Windows with comtypes. Since comtypes uses ctypes, I
    presume it works fine with Python 3 (this is one major advantage of
    using ctypes.)

    Like it or not, Python 3 is the future of Python. It is the Python that
    many Python newcomers learn first, and perhaps ever will. Such students
    usually have no experience or loyalty to any other GUI package, and I am
    sure that many would love to be able to develop apps that they can run
    on their desktop, give to friends to run in a browser, and run on their
    phones.

    --
    Terry Jan Reedy
  • Lkcl at May 17, 2011 at 4:07 pm

    On May 4, 7:37?pm, Terry Reedy wrote:
    On 5/4/2011 10:06 AM, Luke Kenneth Casson Leighton wrote:

    after a long delay thepyjamasproject -http://pyjs.org- has begun the
    0.8 series of releases, beginning with alpha1:
    https://sourceforge.net/projects/pyjamas/files/pyjamas/0.8/
    pyjamasis a suite of projects, including a python-to-javascript
    compiler
    As you well know, there is no such thing as 'python' when it comes to
    compiling actual code. So please specify both in announcements here and
    on the project homepagehttp://sourceforge.net/projects/pyjamas/
    which versions are supported. I do not really want to have to download
    and experiment to determine whether to bother downloading.

    If you do not yet support 3.x, I request and recommend that you do so,
    with the situation as it is, there is not a snowball in hell's chance
    that's going to happen.

    allow me to explain.

    the python translator in pyjamas is heavily dependent on the
    "compiler" module (which is written in c) and is in turn, as you are
    no doubt aware, specifically dependent on the grammar file. the
    python translator for pyjamas 0.3 was 1,200 lines of code. thanks to
    some brilliant and dedicated work by kees bos, over something like a 6
    month virtually full-time period, it's now somewhere around 5,000
    lines of heavily-dense code in which very specific javascript
    optimisations have been encoded.

    then, on top of that, it is necessary to implement the data types
    that are supported in python 3.x, along with several built-ins
    (exceptions etc.). the basic implementation - pyjslib.py - is 6,700
    lines of python code with in-built hand-optimised javascript, and it
    would be necessary to reimplement / re-work... and then support...
    that reimplementation.

    then, on top of that, there are a number of python-based
    reimplementations of various python modules, such as md5.py, re.py,
    string.py and so on, each of which would have to be double-checked for
    compatibility with their python 3.x counterparts. do they exist, have
    they been rewritten, modified etc.`

    then, on top of that, it is necessary to run the pyjamas UI code,
    which is some 15,000 lines of code, along with the other libraries
    such as GChart, through lib2to3, and then to double-check them.

    then, on top of that, it is necessary to run the examples - of which
    there are 70 - again through lib2to3. i've just done a "wc" on the
    examples source code: it comes to a whopping total of 60,000 lines of
    code.

    so you have to do all this work, and really it's impossible to begin
    realistically checking that it works until you get to the LibTest
    example (which is the main test suite, comprising some 3,000 or so
    regression tests), and once you've done all that work you now need a
    userbase and also some maintainers.

    and, when it comes to doing a release, you need to test all 70
    examples in a matrix of 14 browsers plus 4 desktop runtime engines,
    and the browsers you need to recompile three times - with -O
    (optimised), --strict (python-compliant) and there's one more, i
    forget its name, it's designed to minimise the amount of javascript
    generated.

    to support 3.x therefore requires a complete and utter rewrite, and
    then a hell of a lot of work on top of that. it's basically
    supporting a totally separate language, and so is basically a
    completely new project. i know you mean well, but... you've
    drastically underestimated quite how much effort has gone into the
    pyjamas project - just look at the ohloh statistics for goodness sake!
    it's listed as having had 31 man-years gone into it! http://www.ohloh.net/p/pyjamas

    so if you can find the money to get people paid to create a python
    3.x to javascript compiler, which will require approximately twelve to
    fifteen man-months of full-time dedicated programming effort, please
    do speak up!

    otherwise please - really: just saying "give me support for python
    3.x or else" is ... honestly - it's a free software project, _not_ a
    paid-up corporate google/nokia/ibm/redhat/etc. funded project: you
    know the score, and you know the drill.

    now.

    leaving _that_ aside, there happens to be absolutely no really good
    compelling reason to support python 3.x in the first place. "python 3
    is the future of python" gimme a break!! [so why is archlinux the only
    linux distribution that's converted over to run everything off of
    python 3.x?]

    the thing is: there aren't really any major dependencies to "get in
    the way" in pyjs. as in: it's entirely self-sufficient [it has to
    be]. even the installation has its own sandbox system. the only
    dependency *is* python 2.N, and when daniel kluev completes his
    GSoC2011 project, that'll be a "bootstrap" into javascript, including
    the translator itself being compiled into javascript, and then not
    even python 2.N will be a dependency!

    the bottom line is this: somewhere in the next 8 to 10 years, python
    2.N will be deprecated in all but the most die-hard places. at *that*
    time, it will have been worthwhile to convert pyjamas over to python
    3.N - and probably not even then would it be strictly necessary.

    the only really compelling reason would be if it became difficult for
    the pyjamas-desktop engines to be compiled for python 2. that's
    MSHTML (python-comtypes for python 2 disappearing or being hard to
    get) - i'm the maintainer of the pyjd/mshtml.py engine so that'll be
    around for a long time; pythonwebkit (again, i'm the maintainer, so
    that'll be around for a long time) and xulrunner / python-xpcom and
    python-hulahop (python-xpcom is maintained by activestate.com).

    so - if it becomes "difficult" to get hold of all the pyjd engines,
    *then* and *only* then does it make sense to look at converting to
    python 3. i seriously, seriously doubt that pythonwebkit, python-
    comtypes or python-xpcom for python 2 are going to disappear within
    the next 5 years, don't you?

    l.

    p.s. if you _really_ want to use python 3 with pyjs, then run the pyjs
    translator code through lib2to3, and then make damn sure that you use
    the "--internal-ast" option when compiling [this is what is
    recommended for people who use python 2.4, or 2.7 and above. one
    minor change and we might even be able to support python 2.3 or
    below]. you will then use the (duh) internal AST code in pyjs, and
    will *still* need to write pyjamas applications that are in python 2.N
    syntax, because that's what the pyjs translator supports. but you
    will at least not require an http://python.org version 2.N
    interpreter.

    p.p.s for anyone who might be interested, the --internal-ast code sort-
    of came from the lib2to3 project, and was used to create a module
    which is entirely compatible with the standard http://python.org
    version 2.0 "compile" module and the ast module. except that it
    supports the features of lib2to3 which include line and character
    numbers.
  • Terry Reedy at May 18, 2011 at 1:33 am

    On 5/17/2011 12:07 PM, lkcl wrote:
    On May 4, 7:37 pm, Terry Reedywrote:
    On 5/4/2011 10:06 AM, Luke Kenneth Casson Leighton wrote:
    pyjamasis a suite of projects, including a python-to-javascript
    compiler
    As you well know, there is no such thing as 'python' when it comes to
    compiling actual code. So please specify both in announcements here and
    on the project homepagehttp://sourceforge.net/projects/pyjamas/
    which versions are supported.
    [no response]
    I would still like to know. Do you fully support 2.7? It has many of the
    same changes that are in 3.1 and even 3.2 so I can imagine it would be
    difficult.
    If you do not yet support 3.x, I request and recommend that you do so,
    with the situation as it is, there is not a snowball in hell's chance
    that's going to happen. allow me to explain.
    Thank you for the explanation. You are right that I probably
    underestimated the work, though you have or will do some of what is
    needed to fully support 2.7.

    ...
    otherwise please - really: just saying "give me support for python
    3.x or else" is ...
    And I did not say that. I first learned Python with 1.3 and could again
    write 2.x code if motivated.

    ...
    leaving _that_ aside, there happens to be absolutely no really good
    compelling reason to support python 3.x in the first place.
    Depend on who *you* want to target as users. *Your* choice, of course.
    "python 3 is the future of python" gimme a break!!
    Let's discuss that in a couple of years.
    [so why is archlinux the only linux distribution that's converted
    over to run everything off of python 3.x?]
    Because being first is their thing.

    --
    Terry Jan Reedy
  • Lkcl at May 18, 2011 at 9:24 am

    On May 18, 2:33?am, Terry Reedy wrote:
    On 5/17/2011 12:07 PM, lkcl wrote:

    On May 4, 7:37 pm, Terry Reedy<tjre... at udel.edu> ?wrote:
    On 5/4/2011 10:06 AM, Luke Kenneth Casson Leighton wrote:
    pyjamasis a suite of projects, including a python-to-javascript
    compiler
    As you well know, there is no such thing as 'python' when it comes to
    compiling actual code. So please specify both in announcements here and
    on the project homepagehttp://sourceforge.net/projects/pyjamas/
    which versions are supported.
    ?> [no response]

    I would still like to know. Do you fully support 2.7? It has many of the
    same changes that are in 3.1 and even 3.2 so I can imagine it would be
    difficult.
    sorry, terry, missed this out. there are two answers:

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

    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.

    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.

    this is why it's been so unnecessary to keep absolutely up-to-date
    with the full python development that's been going on, yet we still
    have people developing 10,000+ LOC 2 man-year pyjamas projects.

    that having been said, there _is_ the requirement to be "python
    strict" as well as "fast" - mutually exclusive of course. and there
    is someone working on getting the pyjs compiler and supporting
    libraries into shape in order to run the entire http://python.org
    regression test suite. there really are quite a lot of little sub-
    projects within the pyjamas project.

    If you do not yet support 3.x, I request and recommend that you do so,
    with the situation as it is, there is not a snowball in hell's chance
    that's going to happen. allow me to explain.
    Thank you for the explanation.
    not a problem.
    You are right that I probably underestimated the work,
    yeah... i apologise for the somewhat-evident flabbergasted tone that
    may have been apparent in what could otherwise be considered to be a
    project outline / roadmap :)
    though you have or will do some of what is
    needed to fully support 2.7.
    weell... see above: it's kiinda unnecessary - it just depends on
    people's needs. if there are intelligent and willing people (like
    kees) who just come along and go "yep, that's nice, but it's not good
    enough for me: i'm going to make it so" then it'll happen. everyone
    else _not_ willing to put in the effort to make pyjs do what they want
    will just have to put up with the foibles.

    so if someone wants to do it, hell i'm not going to stand in the way
    - anyone who asks i give them commit rights, point them at the
    DEVELOPER.RULES and let them get on with it.
    ...
    ? 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.
    "python 3 is the future of python" gimme a break!!
    Let's discuss that in a couple of years.
    :) 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...

    l.
  • Lkcl at May 18, 2011 at 1:35 pm

    On May 18, 10:24?am, lkcl wrote:

    ? 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.
    in case it wasn't clear, i apologise for doing that :)
  • Terry Reedy at May 18, 2011 at 10:02 pm
    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
  • Lkcl at May 19, 2011 at 1:17 pm

    On May 18, 11:02?pm, Terry Reedy 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.
  • Harrismh777 at May 17, 2011 at 4:38 pm

    Terry Reedy wrote:
    Like it or not, Python 3 is the future of Python. It is the Python that
    many Python newcomers learn first, and perhaps ever will.
    Yes, no doubt, and I'm genuine about that...

    ... but there is something else to consider, as I'm sure you are aware.
    At some point Python is going to have to standardize in order to
    survive. And by survive I'm not talking about the Python 'community,' as
    much as I'm talking about the acceptance and wide-spread use of Python
    by people who just want to get work done and solve problems.

    If there is another major jump like 2.x --> 3.x in the future, Python
    will die. I hope you guys are aware of this. The user base might accept
    this thing once, but they're not going do it again...

    Like it or not, Python 2.x has millions of lines of code running out
    there, and they're not going to get morphed into 3.x coding. So, 2x is
    going to be around for many years to come.

    On the other hand, I'm teaching 3x, coding 3x, and porting to 3x... and
    also encouraging others to do the same... but there is a limit to that
    also. My system has 2.4, 2.5, 2.6, 2.7 and 3.2... and that's the
    trouble with an interpreter. Different versions of the source code (.py
    files) require a matching 'interpreter,' where-as in other languages a
    new compiler version does not require recompiling source, but if source
    is recompiled everything still works... not so in Python. The fact that
    Python is free to morph gleely from PEP to PEP without responsibility or
    accountability with the user base is what may kill Python, unless the
    Python community gets a grip on this concept.


    kind regards,
    m harris
  • Terry Reedy at May 18, 2011 at 1:52 am

    On 5/17/2011 12:38 PM, harrismh777 wrote:
    Terry Reedy wrote:
    Like it or not, Python 3 is the future of Python. It is the Python that
    many Python newcomers learn first, and perhaps ever will.
    Yes, no doubt, and I'm genuine about that...

    ... but there is something else to consider, as I'm sure you are aware.
    At some point Python is going to have to standardize in order to
    survive. And by survive I'm not talking about the Python 'community,' as
    much as I'm talking about the acceptance and wide-spread use of Python
    by people who just want to get work done and solve problems.

    If there is another major jump like 2.x --> 3.x in the future,
    There can't be, in that the essence of the jump was elimination of
    original flaws in 1.0 or 1.1 by elimination of old ways in favor of new
    ways that are already present in 2.7 or before.
    Python will die. I hope you guys are aware of this.
    No, because I think you are exaggerating. That said, I think core
    Python is pretty close to 'complete' and I would not mind further syntax
    freezes like the one for 3.2.
    Like it or not, Python 2.x has millions of lines of code running out
    there, and they're not going to get morphed into 3.x coding.
    Except for public libraries, I do not think it should be.
    So, 2x is going to be around for many years to come.
    For as long the existing binaries can run or a long as the code can be
    compiled.
    with an interpreter. Different versions of the source code (.py files)
    require a matching 'interpreter,'
    Most 2.x code is forward compatible with newer 2.x versions.
    where-as in other languages a new
    compiler version does not require recompiling source, but if source is
    recompiled everything still works...
    Unless the new compiler is for a newer version of the language. I
    believe C89 compilers had problems with some K&R + extensions C. I do
    not know if C89 code is completely C99 compatible. I know the reverse is
    not true, CPython is still C89 code since that apparently still makes it
    available on more machines.

    --
    Terry Jan Reedy
  • Harrismh777 at May 18, 2011 at 5:29 am

    Terry Reedy wrote:
    No, because I think you are exaggerating. That said, I think core
    Python is pretty close to 'complete' and I would not mind further syntax
    freezes like the one for 3.2.
    I am exaggerating only to the extent that someone can imagine folks
    becoming just annoyed with PEP progress to drop the whole thing... I am
    exaggerating only to the extent that we define 'it' as language death...
    if the user base narrows, python's future is held tentative... on the
    other hand, if the user base grows and campers are happy, then python's
    future is more stable... I don't think this is an exaggeration...

    That said, I am encouraged to here your other words, including a favored
    tendency towards syntax freeze... thanks...



    kind regards,
    m harris
  • Lkcl at May 18, 2011 at 9:39 am

    On May 18, 6:29?am, harrismh777 wrote:
    Terry Reedy wrote:
    No, because I think you are exaggerating. ?That said, I think core
    Python is pretty close to 'complete' and I would not mind further syntax
    freezes like the one for 3.2.
    I am exaggerating only to the extent that someone can imagine folks
    becoming just annoyed with PEP progress to drop the whole thing... I am
    exaggerating only to the extent that we define 'it' as language death...
    if the user base narrows, python's future is held tentative... on the
    other hand, if the user base grows and campers are happy, then python's
    future is more stable... I don't think this is an exaggeration...
    one thing that people are not aware of - because it normally simply
    does not make its way out into the public world: you're forgetting
    those people who "just use" python. they don't get onto public
    mailing lists, they don't develop free software projects.

    i've mentioned this story before, but it's worth repeating in this
    context. i worked in a military environment (NC3A) back in
    2006-2007. the version of python that they were using was http://python
    two... point... ONE. six years after its release. why???

    well, it went something like this. someone got the idea that doing a
    portal would be good. so they looked around, and found Zope. so,
    they evaluated the latest version somewhere around ooo april to june
    of 2001. ok they _started_ evaluating it. so, some four months
    later, after doing some coding examples, we're now up to august 2001,
    a decision has to be made by the internal client. they say "yep, go
    for it", but that took another four months (dec 2002). now we do 18
    months of software development (july 2003) to produce a base package.

    now the code now has to be handed over to a team who perform security
    evaluations. this has to be paid for. another six months go by, and
    the security accreditation is received (dec 2004). but this was just
    for the "base" code: now we have deployment and actual product /
    portal development, and a maintenance cycle of 2 years (2006). now
    i'm called in to help with that maintenance and development cycle
    (2007).

    and throughout this time there is *no way* that they can upgrade from
    python 2.1, because it would cost another $EUR 10,000 to get the
    accreditation certificate.

    it's now 2011. for all i know, some TEN YEARS after python 2.1 was
    released, they're still using it.

    you ... _just_ don't normally hear about these kinds of deployments
    of free software, but it illustrates that a particular version can
    hang around for a hell of a long time.

    l.
  • Alex23 at May 18, 2011 at 5:54 am

    harrismh777 wrote:
    If there is another major jump like ?2.x --> 3.x ?in the future, Python
    will die. I hope you guys are aware of this. The user base might accept
    this thing once, but they're not going do it again...
    The differences between major version releases of Python are far, far
    less than those of PHP's _minor_ releases. Hasn't seemed to have
    harmed its uptake at all.
  • Lkcl at May 18, 2011 at 1:42 pm

    On May 17, 5:38?pm, harrismh777 wrote:

    is recompiled everything still works... not so in Python. The fact that
    Python is free to morph gleely from PEP to PEP without responsibility or
    accountability with the user base is what may kill Python, unless the
    Python community gets a grip on this concept.
    he's got a good point, terry. breaking backwards-compatibility was a
    completely mad and incomprehensible decision. i don't believe version
    N of python is going to "die" due to changes - the sheer inertia of
    hundreds of millions of lines of code and hundreds of thousands of
    projects will make sure that's not going to happen, but it doesn't
    help.

    it doesn't matter what the leading-edge developers behind python
    _want_ to happen: it took 10+ years for python 1 and 2 to gain
    traction, and i believe that's the sort of order of magnitude lag-time
    to expect people world-wide to make decisions [to replace code]. you
    only have to look at how long it's taking IE6 to die.... :)

    l.
  • Terry Reedy at May 19, 2011 at 1:13 am

    On 5/18/2011 9:42 AM, lkcl wrote:

    he's got a good point, terry. breaking backwards-compatibility was a
    completely mad and incomprehensible decision.
    I see that I should take everything you (or Harris) say with a big grain
    of salt;-). You just gave me a lecture about the impossibility of doing
    everything one might like with limited all or mostly volunteer
    resources. So surely you can comprehend that the same applies to CPython
    also.

    Given that Python 1.0/1 had some design defects that became evident with
    experience and simply lacked some things thought of later, I can think
    of several options:

    1. Never fix them.

    2. Add fixes, but keep the old stuff. If the old and new ways are
    somewhat compatible, keep both available at the same time*. If they
    conflict, keep old as default and make new available on demand (future
    import)#. This was 2.x strategy.

    2A. Make new ways default and have past imports.

    3. Gradually delete old. This was and is policy mostly for library.

    4. Delete lots of old ways all at once. This was 3.x.

    What would you have had us do instead?

    * Example: old and new style classes. Problems: the differences are hard
    to learn and hard to remember; they are sometimes irrelevant, but
    sometimes not; if you import and instantiate a class, you may not know
    which you have.

    # Example: int division. Problems: having the deprecated meaning be
    default is a damn nuisance; learning it is a stupid burden; if you see
    'a/b' in a snippet extracted from a file, you do not know what it means.

    2.7 is really the end of the road for strategy 2. Keeping obsolete
    features around is a learning burden for most newbies and a maintenance
    burden for developers.

    --
    Terry Jan Reedy
  • Lkcl at May 19, 2011 at 12:42 pm
    [changing subject, seems a good idea...]
    On May 19, 2:13?am, Terry Reedy wrote:
    On 5/18/2011 9:42 AM, lkcl wrote:

    ? he's got a good point, terry. ?breaking backwards-compatibility was a
    completely mad and incomprehensible decision.
    I see that I should take everything you (or Harris) say with a big grain
    of salt;-).
    *lol* - i realise it's a hell of a lot of work to get a python
    interpreter to support two different grammars and syntaxes: you can
    appreciate that i'm in a better position than most to understand that
    [i've also done a port of python to gnu-win32 so am familiar with the
    codebase]

    now that the code for both has been written, tested and proven, the
    task of adding one t't'othr is a leetle less of a challenging task.

    there is one teeny tiny annoying challenge: namespace clashes in c,
    of functions and data structures between the two codebases. however,
    this isn't as bad as it first seems. it's only the "public" face
    (Python.h) which has to remain the same, and that can be taken care of
    by having data structures that are identical internally and externally
    (macros to the rescue) where the internal name is Python2_xxxx and the
    external name Python_xxx.

    where it becomes less of a maintenance burden is when you say "ok,
    that's it: definitely end-of-the-road for all 2.N development,
    period".

    has anyone considered the idea of literally creating a Python2/
    subdirectory in the python3 codebase, literally just dropping the
    entire python2.N code directly into it, renaming all functions and
    data structures, adding a "--2-compatible" switch to the python3 argc/
    v and seeing what happens?

    no interoperability, no maintenance, no "compatibility" - just
    "support for python 2 directly in the python3 binary".

    l.
  • Steven D'Aprano at May 19, 2011 at 10:40 pm

    On Thu, 19 May 2011 05:42:29 -0700, lkcl wrote:

    has anyone considered the idea of literally creating a Python2/
    subdirectory in the python3 codebase, literally just dropping the entire
    python2.N code directly into it, renaming all functions and data
    structures, adding a "--2-compatible" switch to the python3 argc/ v and
    seeing what happens?

    no interoperability, no maintenance, no "compatibility" - just
    "support for python 2 directly in the python3 binary".
    No maintenance?

    The code won't maintain itself, people using it won't stop reporting
    bugs. Are you suggesting that the CPython developers should just grit
    their teeth and refuse to maintain or support code that is part of the
    official release?

    Who is your suggested user-base? Those who want support for 2.7 to
    continue won't be happy with an unmaintained, unsupported compatibility
    layer. Those who are happy to keep on using obsolete software won't need
    this compatibility layer, they can just keep using the Python 2.7 they
    already have. Or 2.5, or 1.5 if they prefer. (I have 1.5 on my machine,
    installed from source, and it works perfectly well.)

    And what of the others? Jython, IronPython, PyPy, Stackless ... once they
    make the move to Python 3 compatibility, are they expected to implement
    this compatibility layer as well?

    I dare say that once the original developers stop supporting Python 2.7
    in three or seven(?) years, there will be a good niche for some
    commercial distribution like ActiveState to continue support. Or one of
    the many critics who insist that Python 3 is a mistake can put their
    money where their mouth is and continue support themselves.

    After all, Python is open source. Somebody (you?) could even fork the
    code base and implement your suggested compatibility layer, or backport
    Python 3 features, be really daring and create a 2/3 hybrid.



    --
    Steven

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
grouppython-list @
categoriespython
postedMay 4, '11 at 2:06p
activeMay 19, '11 at 10:40p
posts18
users6
websitepython.org

People

Translate

site design / logo © 2022 Grokbase