[Interest] pyotherside is Awesome

[Jason H]

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 <charleyb123 at gmail.com>
To: Jason H <scorp1us at yahoo.com> 
Cc: Qt Interest <interest at 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 <scorp1us at 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 <charleyb123 at gmail.com>
>To:Qt Interest <interest at 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 at qt-project.org
>http://lists.qt-project.org/mailman/listinfo/interest
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/interest/attachments/20140219/61d498aa/attachment.html>