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
