pypy appears to have entirely removed all mention of javascript back-end support from web site
hi, i was just checking http://wiki.python.org/moin/WebBrowserProgramming specifically the python-to-javascript compiler section and was surprised to find that the link to the "JS Using" tutorial no longer works. on further investigation, it would appear that pypy have completely removed all mention of javascript as a back-end from the pypy documentation. all tutorials are gone. the demo "bnb" fails. as the lead developer of pyjamas, the python-to-javascript compiler, this leaves me slightly ... concerned, as it implies that pyjamas is now the sole and exclusive free software python compiler which can be used seriously by developers to create web applications. what seems to be the problem? is there a technical / language-translation issue that cannot be overcome? someone said (on the LLVM unladen/swallow list) that adding advanced features like metaclass support would be hard - this was proven to be incorrect, by writing an implementation of "type()" for pyjamas in under 24 hours and about 100 lines of javascript. pyjamas is tiny by comparison (it uses the existing AST / Compiler module / translator) to pypy, so there is very little actually going on, which makes it that much easier to follow its example. the main pyjs compiler is what... 1400 lines of python, and pyjslib.py which contains the majority of the builtins (dict, list, tuple, str) is a further 1400 lines. so - what seems to be the problem? or am i mistaken and the javascript back-end support is just in the process of being rewritten? l.
JS backend is translating restricted subset of Python called RPython. This seems to be infeasible, since JS is truly a dynamic language, that's why we removed it. The other reason why we removed it, is that noone seems to be interested enough in maintaining it. As far as I know pyjamas does not translate a subset of python, but pythonized javascript - ie it does not preserve python features, but rather tries to implement python syntax which is javascript at the bottom. Cheers, fijal On Wed, Apr 22, 2009 at 6:45 AM, Luke Kenneth Casson Leighton <lkcl@lkcl.net> wrote:
On Wed, Apr 22, 2009 at 2:48 PM, Maciej Fijalkowski <fijall@gmail.com> wrote:
JS backend is translating restricted subset of Python called RPython. This seems to be infeasible, since JS is truly a dynamic language,
yes. the features of javascript are a near one-to-one match with python. the only things that are "truly" missing are the int / float bugbear (which can be emulated, i realise, but in a _very_ expensive way), read-only attributes (slots) but even that could be [expensively] emulated, and "undefined" tends to get in the way a lot.
that's why we removed it. The other reason why we removed it, is that noone seems to be interested enough in maintaining it.
oh. arse. well, i have to say: if pypy was in a position to do the same job as pyjamas, i'd be using pypy, not pyjamas. and would end up maintaining it (just like i've ended up maintaining pyjamas, because i need it, and use it).
As far as I know pyjamas does not translate a subset of python,
correct. we're going for as much of python2.N as we have time for, with a view to (eventually) making pyjs a JIT python accelerator (using V8 as the JIT engine) - just like psyco and unladen/swallow.
for web developers, it preserves as many python features in their entirety as web developers can stand. int/float got sacrificed, because that really _is_ too tricky to handle / too expensive to do "strictly". everything else, we're going for preserving / implementing python features as much as possible, simply because people need it. however there's a separate experiment - "strict mode" - which will involve doing a python "int" class and a python "long" class etc. etc. that implement the full semantics. l.
Please. It's completely not like psyco in a sense that you don't support full python. It's super easy to provide 95% of python in a reasonable speed, just the last 5% gets tricky. It's not like you're going to support as much of python2.N as you have time for. You're supporting some intersection between python, js and something else. And that's exactly the reason why JS backend is abandonded. We found out it's impossible to provide a reasonable subset of python under JS, still being a subset and not being something which has a common intersection. Cheers, fijal
On Wed, Apr 22, 2009 at 3:46 PM, Maciej Fijalkowski <fijall@gmail.com> wrote:
that's the plan.
It's super easy to provide 95% of python in a reasonable speed, just the last 5% gets tricky.
that's what i'm going to find out.
in "web mode" - yes. in "strict" mode, i have hopes that an implementation of e.g. int as a python class, compiled to javascript, can be hooked into a drastically-modified version on python intobject.c which e.g. in intobject.c's "int_div()" function actually calls _back_ into javascript-land. likewise for longobject.c and all other basic http://python.org types in the Object/ subdirectory.
such as int / float - yes, i know, and the fact that "hello" + 5 equals "hello5" not a TypeError. the thing is, that for web developers, that's "good enough". we haven't had a single complaint, on the pyjamas-dev lists, and myself and bernd are the only ones that are grumbling about it, because we're the ones that are experimenting in implementing "strict" mode - all the web developers (users of pyjamas) haven't even _noticed_! :) web developers don't care if 5 / 2 = 2.5 (not 2) because if they were doing pure javascript they would suffer the same thing: automatic conversion of int to float. pyjamas allows them to avoid doing pure javascript, and that's all that they care about. so i urge you to reconsider dropping support for JS on the basis that what it provides is actually _beneficial_, and very _much_ not a failure. plus - remember - ECMAScript / Harmony is on the way, and that _does_ support the python concept of "slots", it _does_ have a 32-bit "int" type (i have warned them that they really need a 64-bit "int" type as well as unsigned int32 and unsigned int64). so - basically - don't give up hope is all i can say. remember - javascript is fast becoming one of the most ubiquitous and most heavily-optimised programming languages on the planet (thanks to web browsers) so it's a bandwagon that would be a good idea to work out how to hitch a ride on. l.
Luke Kenneth Casson Leighton wrote:
I'm sure it's "good enough" for pyjamas developer (and I'd probably use it by myself if I were forced to do serious web development), but it's still not python :-). So, what does it mean for an alternative implementation to "be Python"? My primary criteria (but I'm sure that most if not all pypyers agree with me) is that I should be able to run my unmodified program both on CPython and on the alternative implementation and get the very same results. Alternatively, if we talk about a subset, the criteria is that *if* my program runs it *needs* to give the very same results (if it doesn't... well, that's why it's a subset :-)). This is clearly not true for pyjamas, and that's why I (we?) prefer to describe it as a language with a Python syntax and a Python-like semantics. ciao, Anto
well, pyjamas came "from" the area of web development (where the merged/subset stuff doesn't matter and is actually desirable). and i just wanted to emphasise to you that, from experience, the "good enough" really _is_ good enough, for web developers' purposes - and that you should talk much louder and make a much bigger deal of the javascript back-end than is currently being made. if you can add in "assembly-level-like" infusion, where javascript snippets can be substituted directly into the resultant javascript output, then you are on to a winner. the pyjamas compiler uses this technique to directly interface with the DOM model of the browser. however i believe that it would be relatively easy to go from this "good enough" / "relaxed" mode to "full python compliance" - the "strict" mode as i call it. btw i'm glad for the heads-up warning about garbage collection (which someone kindly mentioned in an earlier post) - i don't know enough to fully understand the implications but will, as i progress, keep an eye out for problems, there. once i run into my first brick wall i'll have more of an idea of what you're referring to :) l.
On Apr 22, 2009, at 4:47 PM, Luke Kenneth Casson Leighton wrote:
I'm not going to comment on the merits of this (I actually think javascript is a better language to write javascript code in), but if this is exactly what pyjamas is doing, why would we want to do it on pypy?
Exactly how? How do you map real python to javascript without killing the performance gain any js interpreter is going to give you? Maybe in the future there is going to be a pypy python interpreter running on top of js but without jitting I guess the performance is going to be at maximum in the same level of cpython... which is interesting (having a full python interpreter to run on the client) but not for performance reasons. The way I see real python semantics on javascript is creating a python interpreter in javascript and having tons of checks everywhere (after each math operation for instance) to garantee the same behaviour of cpython. In the end I think that this "relaxed mode" is much more on how Boo works and shold be named as such (naming the language PythonScript or something) to avoid confusion. This mode would have to somehow change the python sintax at least to support messing with prototypes or you are hidding one of the few interesting aspects of the JS language. And the separation from the "relaxed" to "stric" is so big that it should be explict everywhere. -- Leonardo Santagada santagada at gmail.com
In the end I think that this "relaxed mode" is much more on how Boo works and shold be named as such (naming the language PythonScript or something)
ah. i like that. good name. thank you.
well, you can't hide the .prototype or .constructor from objects, and i dread to think what would happen to someone's code if they had a class with "self.prototype" or "self.constructor" in it :) l.
2009/4/22 Luke Kenneth Casson Leighton <lkcl@lkcl.net>
You could call it Javathon :-) Michael
Luke Kenneth Casson Leighton wrote:
in PyPy, typeobject.py and typetype.py contain roughly 1000 lines of RPython code (to which we must add the related logic which is somewhere else). In CPython, typeobject.c contains about 6000 lines of C. Honestly, I doubt a that 100 lines of javascript code can make a python compliant type().
On Wed, Apr 22, 2009 at 3:00 PM, Antonio Cuni <anto.cuni@gmail.com> wrote:
http://pyjamas.svn.sourceforge.net/viewvc/pyjamas/trunk/library/_pyjs.js?vie... see pyjs_type(). it's 58 lines. 89 if you include pyjs_extend() as well. the regression tests are passed, successfully, and the regression tests are also run by the standard python interpreter as well. all i did was copy the lines of code that are auto-generated by pyjs.py (resulting in hard-coded javascript) and put them into that function (pyjs_type) as a "generic" function. it's close enough so that the "hard-coded class generation" could now actually be replaced by a call to pyjs_type() - it's just that pyjs.py is a bit messy so i'm reluctant to do it right now. it may well be the case that there is a lot of functionality of this implementation of type() that i'm missing, that i don't know about, and would welcome comments about it, letting me know what i've missed. for example, i always used to use "if type(clsinstance) == SomeClass" until i was slapped on the wrist and told to use isinstance, but the code i have there in pyjs_type i _know_ won't support that. l.
JS backend is translating restricted subset of Python called RPython. This seems to be infeasible, since JS is truly a dynamic language, that's why we removed it. The other reason why we removed it, is that noone seems to be interested enough in maintaining it. As far as I know pyjamas does not translate a subset of python, but pythonized javascript - ie it does not preserve python features, but rather tries to implement python syntax which is javascript at the bottom. Cheers, fijal On Wed, Apr 22, 2009 at 6:45 AM, Luke Kenneth Casson Leighton <lkcl@lkcl.net> wrote:
On Wed, Apr 22, 2009 at 2:48 PM, Maciej Fijalkowski <fijall@gmail.com> wrote:
JS backend is translating restricted subset of Python called RPython. This seems to be infeasible, since JS is truly a dynamic language,
yes. the features of javascript are a near one-to-one match with python. the only things that are "truly" missing are the int / float bugbear (which can be emulated, i realise, but in a _very_ expensive way), read-only attributes (slots) but even that could be [expensively] emulated, and "undefined" tends to get in the way a lot.
that's why we removed it. The other reason why we removed it, is that noone seems to be interested enough in maintaining it.
oh. arse. well, i have to say: if pypy was in a position to do the same job as pyjamas, i'd be using pypy, not pyjamas. and would end up maintaining it (just like i've ended up maintaining pyjamas, because i need it, and use it).
As far as I know pyjamas does not translate a subset of python,
correct. we're going for as much of python2.N as we have time for, with a view to (eventually) making pyjs a JIT python accelerator (using V8 as the JIT engine) - just like psyco and unladen/swallow.
for web developers, it preserves as many python features in their entirety as web developers can stand. int/float got sacrificed, because that really _is_ too tricky to handle / too expensive to do "strictly". everything else, we're going for preserving / implementing python features as much as possible, simply because people need it. however there's a separate experiment - "strict mode" - which will involve doing a python "int" class and a python "long" class etc. etc. that implement the full semantics. l.
Please. It's completely not like psyco in a sense that you don't support full python. It's super easy to provide 95% of python in a reasonable speed, just the last 5% gets tricky. It's not like you're going to support as much of python2.N as you have time for. You're supporting some intersection between python, js and something else. And that's exactly the reason why JS backend is abandonded. We found out it's impossible to provide a reasonable subset of python under JS, still being a subset and not being something which has a common intersection. Cheers, fijal
On Wed, Apr 22, 2009 at 3:46 PM, Maciej Fijalkowski <fijall@gmail.com> wrote:
that's the plan.
It's super easy to provide 95% of python in a reasonable speed, just the last 5% gets tricky.
that's what i'm going to find out.
in "web mode" - yes. in "strict" mode, i have hopes that an implementation of e.g. int as a python class, compiled to javascript, can be hooked into a drastically-modified version on python intobject.c which e.g. in intobject.c's "int_div()" function actually calls _back_ into javascript-land. likewise for longobject.c and all other basic http://python.org types in the Object/ subdirectory.
such as int / float - yes, i know, and the fact that "hello" + 5 equals "hello5" not a TypeError. the thing is, that for web developers, that's "good enough". we haven't had a single complaint, on the pyjamas-dev lists, and myself and bernd are the only ones that are grumbling about it, because we're the ones that are experimenting in implementing "strict" mode - all the web developers (users of pyjamas) haven't even _noticed_! :) web developers don't care if 5 / 2 = 2.5 (not 2) because if they were doing pure javascript they would suffer the same thing: automatic conversion of int to float. pyjamas allows them to avoid doing pure javascript, and that's all that they care about. so i urge you to reconsider dropping support for JS on the basis that what it provides is actually _beneficial_, and very _much_ not a failure. plus - remember - ECMAScript / Harmony is on the way, and that _does_ support the python concept of "slots", it _does_ have a 32-bit "int" type (i have warned them that they really need a 64-bit "int" type as well as unsigned int32 and unsigned int64). so - basically - don't give up hope is all i can say. remember - javascript is fast becoming one of the most ubiquitous and most heavily-optimised programming languages on the planet (thanks to web browsers) so it's a bandwagon that would be a good idea to work out how to hitch a ride on. l.
Luke Kenneth Casson Leighton wrote:
I'm sure it's "good enough" for pyjamas developer (and I'd probably use it by myself if I were forced to do serious web development), but it's still not python :-). So, what does it mean for an alternative implementation to "be Python"? My primary criteria (but I'm sure that most if not all pypyers agree with me) is that I should be able to run my unmodified program both on CPython and on the alternative implementation and get the very same results. Alternatively, if we talk about a subset, the criteria is that *if* my program runs it *needs* to give the very same results (if it doesn't... well, that's why it's a subset :-)). This is clearly not true for pyjamas, and that's why I (we?) prefer to describe it as a language with a Python syntax and a Python-like semantics. ciao, Anto
well, pyjamas came "from" the area of web development (where the merged/subset stuff doesn't matter and is actually desirable). and i just wanted to emphasise to you that, from experience, the "good enough" really _is_ good enough, for web developers' purposes - and that you should talk much louder and make a much bigger deal of the javascript back-end than is currently being made. if you can add in "assembly-level-like" infusion, where javascript snippets can be substituted directly into the resultant javascript output, then you are on to a winner. the pyjamas compiler uses this technique to directly interface with the DOM model of the browser. however i believe that it would be relatively easy to go from this "good enough" / "relaxed" mode to "full python compliance" - the "strict" mode as i call it. btw i'm glad for the heads-up warning about garbage collection (which someone kindly mentioned in an earlier post) - i don't know enough to fully understand the implications but will, as i progress, keep an eye out for problems, there. once i run into my first brick wall i'll have more of an idea of what you're referring to :) l.
On Apr 22, 2009, at 4:47 PM, Luke Kenneth Casson Leighton wrote:
I'm not going to comment on the merits of this (I actually think javascript is a better language to write javascript code in), but if this is exactly what pyjamas is doing, why would we want to do it on pypy?
Exactly how? How do you map real python to javascript without killing the performance gain any js interpreter is going to give you? Maybe in the future there is going to be a pypy python interpreter running on top of js but without jitting I guess the performance is going to be at maximum in the same level of cpython... which is interesting (having a full python interpreter to run on the client) but not for performance reasons. The way I see real python semantics on javascript is creating a python interpreter in javascript and having tons of checks everywhere (after each math operation for instance) to garantee the same behaviour of cpython. In the end I think that this "relaxed mode" is much more on how Boo works and shold be named as such (naming the language PythonScript or something) to avoid confusion. This mode would have to somehow change the python sintax at least to support messing with prototypes or you are hidding one of the few interesting aspects of the JS language. And the separation from the "relaxed" to "stric" is so big that it should be explict everywhere. -- Leonardo Santagada santagada at gmail.com
In the end I think that this "relaxed mode" is much more on how Boo works and shold be named as such (naming the language PythonScript or something)
ah. i like that. good name. thank you.
well, you can't hide the .prototype or .constructor from objects, and i dread to think what would happen to someone's code if they had a class with "self.prototype" or "self.constructor" in it :) l.
2009/4/22 Luke Kenneth Casson Leighton <lkcl@lkcl.net>
You could call it Javathon :-) Michael
Luke Kenneth Casson Leighton wrote:
in PyPy, typeobject.py and typetype.py contain roughly 1000 lines of RPython code (to which we must add the related logic which is somewhere else). In CPython, typeobject.c contains about 6000 lines of C. Honestly, I doubt a that 100 lines of javascript code can make a python compliant type().
On Wed, Apr 22, 2009 at 3:00 PM, Antonio Cuni <anto.cuni@gmail.com> wrote:
http://pyjamas.svn.sourceforge.net/viewvc/pyjamas/trunk/library/_pyjs.js?vie... see pyjs_type(). it's 58 lines. 89 if you include pyjs_extend() as well. the regression tests are passed, successfully, and the regression tests are also run by the standard python interpreter as well. all i did was copy the lines of code that are auto-generated by pyjs.py (resulting in hard-coded javascript) and put them into that function (pyjs_type) as a "generic" function. it's close enough so that the "hard-coded class generation" could now actually be replaced by a call to pyjs_type() - it's just that pyjs.py is a bit messy so i'm reluctant to do it right now. it may well be the case that there is a lot of functionality of this implementation of type() that i'm missing, that i don't know about, and would welcome comments about it, letting me know what i've missed. for example, i always used to use "if type(clsinstance) == SomeClass" until i was slapped on the wrist and told to use isinstance, but the code i have there in pyjs_type i _know_ won't support that. l.
participants (5)
-
Antonio Cuni -
Leonardo Santagada -
Luke Kenneth Casson Leighton -
Maciej Fijalkowski -
Michael Foord