Anthony, this is great input!
Can you do us all a favor? Can you turn your knowledge into a code review on the pull request that Daniel just made? (actually yesterday) E.g. here: https://github.com/gonvaled/pyjs/commit/e91448f45ff74e6ebc0f4cd1256d2cac6c9e4879 (You know how: clicking on the "+" speed bubble - and leaving a note - that, e.g., uses the "wnd()") This would make great into greater! Thanks, Anthony 2012/7/12 C Anthony Risinger <anth...@xtfx.me>: > On Wed, Jul 11, 2012 at 4:08 PM, Daniel Gonzalez <gonva...@gmail.com> wrote: >> >> Thanks istvan, this is working! > > i'm glad your getting it all working (and most certainly via the > 10,000 m/s crash course :-), as your threads are good testaments of > why, should these bidirectional interactions ever be supported, they > MUST pass thru a static, pre-defined, and well-established API, > residing outside-of-and-immune-to the translator feature settings (eg, > __setattr__). the alternatives appear riddled by > hard-to-track-and-mutually-exclusive bugs, explosive > incompatibilities, headaches, ultimately to the satisfaction of no one > (yikes, that came off more pessimistic than intended ... here is > another :-)! > > anyways, i simply noticed some calls to JS eval() in several of your > posted snippets -- why? i am quite certain you'll never need it ... > (if you do, well, {shudder}) just work with python normally 99% of the > time, and when you need to "cross-over", use the > @{{python-identifier-goes-here}} mechanism. > > be leery of wnd() and other quasi-types from __pyjamas__; these are > not general purpose python objects. make *every* operation explicit > (eg. `setattr` vs. relying on language features) and you will go much > further/faster, because most of the translator's `--enable-xyz` > options relate to (dis|en)abling various *implicit* language behaviors > easily performed by the python.org interpreter (__get__, __set__, etc, > etc), but difficult or expensive under pyjs. > > keep it up ... this time next year you'll be hacking on the core :-)
