[PySide] PySide is Dead?

[Hugo Parente Lima]

On Monday, December 10, 2012 12:55:35 PM Joel B. Mohler wrote:
> On 12/10/2012 12:42 PM, John Ehresman wrote:
> > On 12/10/12 12:32 PM, Hugo Parente Lima wrote:
> >>> My thought on the code generator was to have the C++ parser write
> >>> the parse tree out to some xml file that could then be read by a
> >>> code generator written in python.  Then the C++ parser could
> >>> possibly be replaced with something else and the generator could
> >>> be more quickly improved since it's now implemented in python.
> >>> Changing it would still require C++ knowledge, though, because
> >>> it's emitting C++ code.
> >> 
> >> There's GCCXML[1], so the python program just read the output of
> >> GCC XML plus some other file with meta information equivalent to
> >> the current typesystem but less verbose and outputs the binding
> >> code, seems easy, but it's a looooonnng task.
> > 
> > As a first small step, I would modify shiboken to output the parse
> > tree from its internal C++ parser.  I would do this mainly to minimize
> > the changes to the generator and the goal here is to get the generator
> > code converted to python and not to replace the C++ parser.
> > 
> > Later, alternative parsers could be investigated and perhaps used --
> > something based on gcc worries me though because it may not be easy to
> > install and use on Windows.
> 
> I've had some very good luck auto-generating things based on clang using
> advice written at
> http://eli.thegreenplace.net/2011/07/03/parsing-c-in-python-with-clang/
> .   It was pretty straightforward to get the needed clang tool chain
> running on windows in spite of some negative comments somewhere about
> that.  I actually was generating cython code from mako templates and
> generating each function by iterating over parsed functions which met
> the desired criteria.  The major elements of PySide which I did not
> cover were the ability to override c++ virtual functions in python and
> the python/c++ object lifespan synchronization.  Both of these are
> non-trivial elements which no naive cython wrapper will resolve.
> 
> One annoying issue I had (which may or may not matter) is that compiling
> a certain .h file in our code was an order of magnitude slower with
> clang than with MSVC.  The obvious caveat is that MSVC was likely using
> pre-compiled headers somehow, but I'm 95% certain it was not.  I suspect
> this speed issue is resolvable.
> 
> In a nut-shell:  I still working this project, but I'm left very
> impressed with the clang-parser and associated python bindings.  But
> it's a lot of work to recreate PySide based on those notions. (Caveat:
> technically I was iterating over c-structs with function pointers, but I
> believe the clang c++ support is sufficient to iterate over real classes.)

The only problem I see of the lack of support for signals and slots, the 
parser used by Shiboken identifies Qt signal and slots in the headers, the 
clang parser may just ignore them like a normal compiler would do, but I think 
this can be solved with some "pre-processor workarounds".
 
> Joel
> 
> _______________________________________________
> PySide mailing list
> PySide at qt-project.org
> http://lists.qt-project.org/mailman/listinfo/pyside
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.qt-project.org/pipermail/pyside/attachments/20121210/e7b0364a/attachment.sig>