On 1/14/13 4:36 PM, Robin Dunn wrote: > On 1/14/13 1:40 PM, Николай wrote: >> FYI current wxPython is based on SWIG, next version is using SIP. >> AFAIK SWIG is not python specific which makes it sub-optimal. > > Indeed. I am very happily leaving SWIG behind as the code generated by > SIP is smaller, faster, more robust and has less of a memory footprint > at runtime. And because of being focused on just Python it is a little > easier to make things a bit more pythonic from the user's perspective > too. Switching PySide to SWIG would definitely be a step backwards IMO.
BTW, I should probably also mention that most of the SIP code in the new wxPython (aka Project Phoenix) is currently being generated too. The intent of that generator is to be able to write code for multiple back-ends, although currently the only generators are for the SIP code, *.pi files for WingIDE, and Sphinx docs. The input for the class definitions is coming from XML generated by Doxygen when processing the wx C++ documentation, but that could probably be made pluggable too. The key principle is that the input processor creates a collection of object trees which define the classes, methods, functions, etc. to generate code for, then there is a stage where information in those objects can be changed or added to, and then one or more back-end generators can be run with that collection of objects as inputs. More information about the project and source can be found at http://wiki.wxpython.org/ProjectPhoenix. Although the intent is that it would not care about the backend or even what collection of classes it is generating code for, there are several SIP and wxPython specific things that have crept in along the way. I wouldn't mind cleaning those out however if there is some desire to use part or all of this for future PySide implementations. -- Robin Dunn Software Craftsman http://wxPython.org _______________________________________________ PySide mailing list [email protected] http://lists.qt-project.org/mailman/listinfo/pyside
