[PySide] PySide - Qt5 - Swig

Mon Jan 14 11:04:25 CET 2013

Ah, I accidentally sent the unfinished version of my email..

2013/1/14 Roman Lacko <backup.rlacko at gmail.com>

> 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 ?
>
There is no list of developers or contributors. Who is actually resposible
for what or better say who want to be responsible for what ? I personally
will continue do support the pyside-setup build scripts, it's my hobby
project, but because i love python and qt i will do it for free.

>
> 2. Is Digia interested to sponsor development ?
>
Someone should contact people at Digia, Maybe Digia would be interested to
support the development ? I personally would love see PySide supported at
the same level like Qt is.

Regards
R.

> 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/6d159a38/attachment.html>