On Sat, May 26, 2012 at 1:51 AM, Peter Bittner <[email protected]> wrote: > 2012/5/24 Rob Peters <[email protected]>: >> On 2012-05-24 15:30, Peter Bittner wrote: >>> >>> Oooops, that's starts getting interesting! >>> >>> What if Pyjs would integrate all kinds of JS frameworks (mostly some >>> that provide UI widgets, I would suppose) and one could say at compile >>> time (or so) which one to use for the generated application!? ... >>> Sounds ... awesome ... scary ...<your opinion here> >>> >>> - Who would decide on what framework would make it into Pyjs? >>> >>> - What would the design look like that makes it possible to do such a >>> thing? (i.e. using the same Python code that generates a web app with >>> the widget library of your choice) >>> >>> Not sure whether this would entail any serious disadvantages, issues, >>> challenges. >>> >>> Peter >>> >> It is interesting, but I'd rather "Do One Thing Well" first. I vote for >> tracking GWT step-for-step, and making PYJS attractive because it has all >> the advantages of Google's engineering, plus the pure joy of working in >> Python. I don't care if alternative frameworks are added later, but the GWT >> widgets aren't even 100% now. I think an automated conversion process that >> kept us on the bleeding edge (we can still use that metaphor here, can't we? >> :)) of GWT development would, mixed with the advantages of Python, make us a >> killer project. > > Absolutely, I agree! 100% positive. > >> Just my two cents. I was in PYJS (and loved developing with PYJD), but am in >> GWT now because the widgets and compiler just aren't in the same league as >> GWT is currently (my PYJS application was 5MB, my GWT application (which is >> feature-identical) is 200kb). I'd love to go back to PYJS. I coded twice as >> fact and loved the flexibility and fewer lines of code. But it's just not >> industrial strength yet. > > If that's really the case that newer GWT releases result in a much > smaller generated code (i.e. if it's not the pyjs compiler's fault) > then this point only would be a great relief for me too! I still > hesitate to recommend Pyjs for, e.g., small feature additions to a > website - which should be possible with Pyjs I think, not only huge > applications made of 100% Pyjs - because it just would put a huge > performance burden on the website. > > Pair it with the lastest and greatest of current GWT development, and > let's stick with calling it "scarry bleeding ouch ouch ouch I am > bloodyedge", haha! ;-)
i'm about to call it a night ... probably short-ish? :-) i wanted to note that exposing python in a meaningful way to JS was not what i had in mind. the comment RE: "welcoming 3rd-party libs" was in the context of other python libs specifically. i also didn't mean to imply they'd be included proper, or affiliated in any tighly-coupled way ... i simply meant that by making the toolchain simpler to use and more self-contained, it would apply more generally and be viable to those with use-cases other than widget libraries and single-page webapps. ... as for included libraries, the core toolchain would likely be nothing more than the translation stack, the Python stdlib, and (DOM|Window|Timer|[ie. W3C ...]).py, and possibly runtime support for the native variants (ie. "pyjd") ... basically the bare minimum to write python and interface with a browser engine; nothing more, nothing less. bidirectional communication with JS is very complex and tricky sleight of code. the translator can output varying levels of "python-y-ness" that are not semantically compatible with each other, without even considering the massive proliferation amongst JS libraries. you really have to keep in mind that in the context of pyjs, JS is the *assembly* language, and Python is the actual C-source ... doing complex -- and properly accounted/managed -- operations on C-level items from raw assembler is far from trivial, and while we are lightyears from that playground, the barriers are similar. alas, tools like libffi (foreign function interface) *do* perform bridges of a somewhat similar vein; this is the mechanism used by ctypes module to access compiled objects -- IIUC from my dabblings in pygi code, the "real" foreign objects are represented by an empty shell of sorts in the local language (contrast with foreign), and manipulations on these mirages are marshaled to the foreign object and carried out there. perhaps with some kind of stable-ish interface/conventions a libjsffi and libpyffi could be created for Python and JS, respectively ... no idea. this is further complicated by the fact that JS is a powerful high-level language, but it's utter lack of basic language constructs has led to massive "do-it-yourself" impls ... there has got to be 10,000 different ways to implement a basic "class" out there -- few or none compatible AFAIK. TBH, i don't know how large a role that would even play, but my gut tells me that C code, being much more "defined" and hence only so much is possible, contributes to how libffi does it's magic ... whereas JS is a closure-happy runaway circus sideshow in comparison. there are some non-C examples on libffi main page, like JS and Python -> ObjC, but still pretty well-defined target/foreign langs. pygi/gobject-introspection actually uses libffi to call the real GObjects in C, from Python. however this only works as great as it does *if* everyone plays along -- you must use GObject, and your sources must be properly annotated with enough hints to make stuff work for the bits that can't be deduced ... else ambiguous functions/structures won't be exposed to Python at all (*cough* add/removeEventListener() for example ;-). but again, i'm not 100% sure how this would translate to our own endeavors. lastly ... some of the ideas i have in mind actually make the generated code *significantly more difficult* to interface with _directly_ (sans some predetermined gateway interface that is) ... simply because its generated for speed/quality/size: after all, it is the output of a compiler! gcc will unroll your loops, inline stuff, and do all sorts of trixy things to improve the final product -- it's a black box not meant for opening, and doing so voids the warranty. i am definitely not discouraging any efforts or discussion here -- i actually think any progress or development towards solution(s) would be incredibly interesting and probably worthwhile -- but i needed to clarify, that at this point in time, it's not a concrete milestone or slated to become one. anyway, it's an R&D project for the intrigued -- maybe someone can and will carry it forward. -- C Anthony
