[Interest] pyotherside is Awesome

Charley Bay charleyb123 at gmail.com
Thu Feb 20 03:17:00 CET 2014


<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/0a505db1/attachment.html>


More information about the Interest mailing list