[PySide] PySide - Qt5 - Swig

[anatoly techtonik]

On Sun, Jan 13, 2013 at 10:43 PM, Fabien Castan <fabcastan at gmail.com> wrote:

>
>  Are people from Shiboken not interested to work on Swig? Why?
>>> I see the reason to eliminate boost python. Is there a reason to
>>> eliminate Swig?
>>>
>> I guess the same reason applies.
>>
>> http://web.archive.org/web/20120311172636/http://www.pyside.org/docs/shiboken/faq.html
>>
>
> The sentence is: "The main reason was the size reduction. Boost.Python
> makes excessive use of templates resulting in a significant increase of the
> binaries size. On the other hand, as Shiboken generates CPython code, the
> resulting binaries are smaller."
> But Swig use CPython too... so I don't see the difference with Shiboken on
> the principle.
>

I guess we need to ask Matti and OpenBossa team then. Your approach
produces larger binaries than PyQt. Do you have the same stats between PyQt
and PySide for comparison?

 One of the reasons to switch to Python is to continue generating docs like
>> that. SWIG will never be able to generate something like this, and it would
>> be nice to make generated HTML available again. GitHub or Google Code
>> should do this.
>>
> I don't see the point. Using the rst format and tools like sphinx is a
> great thing.
> It doesn't depend on the binding tool and you don't need to write your
> application in python to use it.
> readthedocs.org is a great solution to maintain it automatically.
>
The point is that this .rst documentation is generated from Qt
documentation with PySide specific fixes. I am not sure how examples are
corrected, but it seems feasible to correct them automatically from .xml
definitions.


>  Another reason. You said you're able to generate Swig rules from the
>> .xml files of Shiboken. Can you do the reverse?
>>
> Sure an xml is easier to parse from a script than Swig rules. But on the
> other hand, it's far more human readable than xml!
>

It is not about XML. It is about data structure. How to generate something
different than bindings from Swig rules definition? Can I use them in
Sphinx to patch examples in .rst converted from official Qt docs? Can I
read and play with these rules in Python? I know that with XML I can work
without writing a separate parser and it is a matter of minutes to get to
any part of structured data.


> From my point of view, xml is really not a good argument...
>

It is not about XML, it is a question about Swig capabilities.


> Writing such code is not very pleasant:
> <rejection class="*"
> function-name="qobject_interface_iid<QTextCodecFactoryInterface*>"/>
>
> Having 4058 lines of xml in one file for all QtCore... is not
> very comfortable too.
> I have some difficulties to see this, as the best solution for an ideal
> future. Even if the tool that parse it is written in python.
>

So how many lines of what do you propose to make everybody see it without
difficulties? What is your option for the best solution in an ideal future?

I must add that nobody says that this XML format is perfect or final. In
fact nobody designed it to be suitable for PySide - rumors are that it was
stolen from Qt Jambi (Java Qt bindings), and Java people love XML. Probably
because there already were ready to use definitions and some C++ code to
parse them.

Sure it's easier to parse an HTML file than an RST file... but people
> prefer to deal with RST to write their documentation.
>

RST is not the best format. Docutils produce inconsistent markup depending
on the content and this won't change, because of "backward compatibility".
Most people use it only because there is no real alternative to Sphinx.


>  Why not to bring expertise to Boost then?
>>
> Because in Boost Python, the principle is wrong. Using templates to
> creates a binding to a script language is a strange idea...
> I don't see many project using Boost Python. I don't see any project using
> Shiboken.
> But I see a lot of projects using Swig. It should be a reason, no?
>

Shiboken is PySide/Qt only. Few more months of sponsored development and it
could become useful for the rest of the world. As for SWIG, frankly, I
haven't seen a SWIG project in Python for a long time. Even for project
like Subversion that provide official SWIG bindings, people prefer to do
the binding from scratch (Subvertpy, ...) instead of forking existing stuff.

If you're looking at http://www.swig.org/projects.html then this page is
largely outdated. For example PyOpenGL switched from SWIG to ctypes and
don't use SWIG anymore (even though ctypes is slower)
http://pyopengl.sourceforge.net/documentation/opengl_diffs.html

>From other essential game frameworks - Pygame never used it, pgreloaded
does't seem to use it as well. pyglet also doesn't use anything - just
checkout and run. If SWIG does its job well, then why people waste time
doing their manual bindings versions?


> Oops... It seems that I lose my objective to not hurt anybody... ;)
>

You may try, but it will be really hard, so better give up early. =)


>  You again ignore the Py. side of the arguments. In Python world ctypes
>> is way more popular, because it doesn't require compilation and binary
>> blobs. I'd look into CFFI if you really want to move new technology.
>>
> I don't know what is the best way to bind a language to another. I have
> no experience on that, but it seems really interesting.
> Maybe you could discuss with Swig guys. I'm sure they are interested by
> the subject...
> You are both open source, so there is no real concurrency like in
> commercial software. That's the power of open source!
>

Me is not open source. =) I am just another "outsider" in this Qt Project.
The ctypes is the slowest, the most dangerous, but the most convenient
technology when it comes to call external .dll's from Python. CFFI is said
to be its replacement, but I am not sure it is as convenient.

 We all want Qt5 in Python, but in pythonic ways.
>>
> Yes, but if you need to rewrite the binding tool in python before starting
> conversion rules... with nobody in full-time job...
> How could this be achieved?
>

Who said about complete rewrite? The talk is about gradual translation of
logic from C++ to Python.


> I'm surprised that you are not interested to check existing solutions,
> before starting to *REWRITE* Shiboken in python.
>

If I wasn't interested, I didn't participate in this thread. =) I am
interested to see existing solutions, but as I said - I don't understand
C++ code, so I can't really check anything that is written for C++
developers.


> Swig is the most widely used binding tool... maybe you could test it
> before?
> We do something that could be considered as a prototype of that, but if
> you are not interested at all...
>

Prototype that mirrors existing Shiboken bindings would be awesome. There
are tests written for PySide, so if your SWIG bindings pass them - it will
be possible to directly compare sizes and performance. I think SWIG
developers should be very interested in the outcomes.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/pyside/attachments/20130114/e2e64327/attachment.html>