[PySide] PySide - Qt5 - Swig

[Matthew Brett]

Hi,

On Sun, Jan 13, 2013 at 7: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.
>
>> 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.
>
>> 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!
> From my point of view, xml is really not a good argument...
> 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.
>
> Sure it's easier to parse an HTML file than an RST file... but people prefer
> to deal with RST to write their documentation.
>
>> 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?
> Oops... It seems that I lose my objective to not hurt anybody... ;)
>
>> 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!
>
>> 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?
>
> I'm surprised that you are not interested to check existing solutions,
> before starting to REWRITE Shiboken in python.
> 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...

Am I right that the current plausible options for the longer term
maintainability of PySide are:

1) Hope for someone to rewrite shiboken in Python
2) Write a new set of Qt bindings in swig?

And that no-one has so far said that they have time to do the shiboken rewrite?

That - you - Anatoly - are offering time and expertise to try swig in
the near future?

Then surely - as an outsider - the answer must be 'go for it - we'd
love to see how that goes'.  No?

Best,

Matthew