On Sun, Jan 13, 2013 at 8:43 PM, Fabien Castan <[email protected]> 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... ;) > having worked with boost python bindings in the past, I can confirm it's not a good solution, the use of templates makes it difficult to debug, and compilation takes ages ... > > 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... > > > _______________________________________________ > PySide mailing list > [email protected] > http://lists.qt-project.org/mailman/listinfo/pyside > >
_______________________________________________ PySide mailing list [email protected] http://lists.qt-project.org/mailman/listinfo/pyside
