Ah, I accidentally sent the unfinished version of my email.. 2013/1/14 Roman Lacko <[email protected]>
> 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 <[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
