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 <[email protected]> > On Sun, Jan 13, 2013 at 10: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. >> > > 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 > [email protected] > http://lists.qt-project.org/mailman/listinfo/pyside > >
_______________________________________________ PySide mailing list [email protected] http://lists.qt-project.org/mailman/listinfo/pyside
