Error: expected 'peanut butter' before jelly.
On Feb 19, 2014 8:40 PM, "Jason H" <scorp...@yahoo.com> wrote:
> It would be cool if you could do:
>
> Python {
> id: pythonOsPath
> code: `import os
> print (os.path)`
> }
>
> Text {
> text: pythonOsPath.exec()
> }
> Note the back-ticks, which allow multiline, non-substitured strings.
>
>
> ------------------------------
> *From:* Charley Bay <charleyb...@gmail.com>
> *To:* Jason H <scorp...@yahoo.com>
> *Cc:* Qt Interest <interest@qt-project.org>
> *Sent:* Wednesday, February 19, 2014 9:17 PM
> *Subject:* Re: [Interest] pyotherside is Awesome
>
> <keeping the thread below for others to review>
>
> Jason H sayeth:
>
> I think a better approach would have been to drop JS entirely (kill the JS
> Engines) and go with python. Though, I don't know how this would really be
> different from what we have today.
>
>
> That's my curious wondering at present. While I prefer C++, if I'm
> scripting, I think I'd prefer Python over JS. However, JS is so trivial
> that QML implemented its own internal-engine (which I think was a good
> idea, for the strong typing and other internal semantic control). I don't
> know if it is realistic to consider an internal-engine like that with
> Python syntax/semantics (probably not, but I don't know).
>
> I argue for python a lot, but not this time.
>
> I used to code PyQt apps, and loved it. It was fantastically easy. Then I
> used Jython and that was great. I however will not be using this. It's
> just 'off'. I could be missing the point, and if I am, please tell me!
>
>
> I'll defer to the pyotherside Author (if he's monitoring the list and
> wants to comment), but IMHO "pyotherside" really is "different": While
> PyQt and PySide wrap the Qt/QWidget APIs (that's a lot of work),
> "pyotherside" does NOT. It merely embeds a Python engine in your QML apps.
> You can't do GUI with it. You don't have access to anything Qt (no
> widgets, no controls, etc.) Rather, you can only do Python logic.
>
> Then, the QML can "call-into" the Python engine (with all the objects you
> have in there), and can receive "events" from the engine (and those events
> are merely handled through JS callbacks within your QML). It's a very
> small API, and it's merely a "call()" and "evaluate()" API. The author
> made a good decision IMHO to default to "asynchronous", but you can do
> synchronous calls if you want (which you probably shouldn't).
>
> For my use, that's *exactly* what I want. I don't want GUI in my Python.
>
> From my understanding, here's the *ideal* scenario for pyotherside:
>
> (1) You have a command-line tool written in Python. It does a lot of
> stuff, and runs for a long time.
>
> (2) You want to slap a GUI on it, and you want that GUI to be QML.
>
> (3) Use pyotherside.
>
> (4) Profit!
>
> -----------
> A possible "second-scenario" would be:
>
> (1) You have a QML application.
>
> (2) You want to do some non-trivial logic, including some long-lived
> non-GUI stateful objects.
>
> (3) Use pyotherside (to embed into your QML a Python engine that holds the
> long-lived non-GUI stateful objects)
>
> (4) Profit!
>
> -----------
> I suppose a possible third-scenario might be:
>
> (1) You have a QML application.
>
> (2) You want to call a Python function to do something that is not
> natively available in the QML APIs, but it's "out-of-the-box-available" in
> Python. There are so many really weird Python modules and APIs that this
> can often be true.
>
> (3) Use pyotherside.
>
> (4) Profit!
>
> -----------
> Here's my personal most likely scenario:
>
> (1) You need a GUI, so you write it in QML.
>
> (2) You write your logic in C++, deployed as a QML plugin.
>
> (3) You go make yourself a jelly sandwich, while wondering how people can
> live without compile-time syntactic code checks and strong typing.
>
> (4) Profit!
>
> --charley
>
>
> On Wed, Feb 19, 2014 at 6:24 PM, Jason H <scorp...@yahoo.com> wrote:
>
> I took a look at the video. As I'm a HUGE python fan. But I have no idea
> what this is about. At best, it allows you to access python libraries when
> JavaScript falls short, in effect keeping the QML for presentation and
> doing more in Python... But we already have something to use when JS falls
> short: C++ and all its libraries. When I saw the code examples, I thought
> "Eew, you got your python in my QML!" The fact that you have to enclose all
> the python strings in quotes is horrid.
>
> I think a better approach would have been to drop JS entirely (kill the JS
> Engines) and go with python. Though, I don't know how this would really be
> different from what we have today. I argue for python a lot, but not this
> time.
>
> I used to code PyQt apps, and loved it. It was fantastically easy. Then I
> used Jython and that was great. I however will not be using this. It's
> just 'off'. I could be missing the point, and if I am, please tell me!
>
>
>
> ------------------------------
> *From:* Charley Bay <charleyb...@gmail.com>
> *To:* Qt Interest <interest@qt-project.org>
> *Sent:* Wednesday, February 19, 2014 6:18 PM
> *Subject:* [Interest] pyotherside is Awesome
>
> Just a "heads-up", but I spent the last couple weeks playing around with
> "pyotherside", which binds a Python engine into QML ("pyotherside" is
> deployed as a C++ compiled QML plugin).
>
> I am really impressed. It is really awesome -- it integrates well, is
> easy to use, and we can now put QML applications on top of our Python code
> bases. (We are mostly a C++ shop, and we're mostly doing C++ plugins, but
> Python is handy for internal tools and prototyping.)
>
> Main web site:
> http://thp.io/2011/pyotherside/
>
> Latest docs (v1.2):
> http://pyotherside.readthedocs.org/en/latest/
>
> DevDays 2013 Berlin talk here:
>
> http://www.youtube.com/watch?v=2HAFOZ5_Xks&index=17&list=PLizsthdRd0YyV6zOEFYog77IAPV85f7w2
>
> I'm not affiliated with the project -- I'm just tickled at how well it
> integrates into QML. I didn't realize it existed until KDAB put the Berlin
> talks online.
>
> As a silly thought-experiment, IMHO the QML/Javascript is a
> "better-Javascript" because it's strongly-typed and the new QML/JS engine
> is "more-integrated" leading to greater possible bytecode/speed/packaging
> features in the future. However, I'm somewhat curious what the Qt
> community would think about making "Python" a first-class-citizen in the
> QML world. If we did, I'd probably vote for an API that looks like that
> provided through "pyotherside". I have a general "fear/trepidation" with
> putting more-than-trivial logic into Javascript, but I'm less concerned
> about scaling logic through Python.
>
> --charley
>
>
> _______________________________________________
> Interest mailing list
> Interest@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/interest
>
>
>
>
>
>
> _______________________________________________
> Interest mailing list
> Interest@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/interest
>
>
_______________________________________________
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest
