[PySide] PySide - Qt5 - Swig

Roman Lacko backup.rlacko at gmail.com
Mon Jan 14 10:38:39 CET 2013


Hi,
i thing before going to technical details about how to implement new
shiboken there should answered some questions:

1. Who will actually develop and support the development ?


2. Is Digia interested to sponsor development ?


2013/1/13 anatoly techtonik <techtonik at gmail.com>

> 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.
>
>
> _______________________________________________
> PySide mailing list
> PySide at qt-project.org
> http://lists.qt-project.org/mailman/listinfo/pyside
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/pyside/attachments/20130114/8058612a/attachment.html>


More information about the PySide mailing list