Using custom Qt subclasses in Python

First off: I'm new to both Qt and SWIG. Currently reading documentation for both of these, but this is a time consuming task, so I'm looking for some spoilers. It's good to know up-front whether something just won't work.

I'm attempting to formulate a modular architecture for some in-house software. The core components are in C++ and exposed via SWIG to Python for experimentation and rapid prototyping of new components. Qt seems like it has some classes I could use to avoid re-inventing the wheel too much here, but I'm 开发者_JAVA技巧concerned about how some of the bits will fit together.

Specifically, if I create some C++ classes, I'll need to expose them via SWIG. Some of these classes likely subclass Qt classes or otherwise have Qt stuff exposed in their public interfaces. This seems like it could raise some complications.

There are already two interfaces for Qt in Python, PyQt and PySide. Will probably use PySide for licensing reasons. About how painful should I expect it to be to get a SWIG-wrapped custom subclass of a Qt class to play nice with either of these? What complications should I know about upfront?

PyQt exposes C++ code to Python via SIP; PySide does so via Shiboken. Both have roughly the same capabilities as SWIG (except that they only support "extended C++ to Python", while SWIG has back-ends for Ruby, Perl, Java, and so forth as well). Neither SWIG nor SIP and Shiboken are designed to interoperate with each other. You couldn't conveniently use SWIG to wrap any code using the C++ extensions that Qt requires (to support signals and slots) and I have no idea what perils may await you in trying to interoperate SIP-wrapped (or Shiboken-wrapped) and SWIG-wrapped code.

Why, may I ask, have you chosen to use two separate and equivalent ways to wrap different parts of your C++ codebase (Qt via SIP or Shiboken, everything else via SWIG)? If you can still reconsider this weird design decision I would earnestly recommend that you do so.

If your choice of SWIG is carved in stone, I predict big trouble any time you're wrapping C++ code using Qt extensions (i.e., slots or signals) and a generally thoroughly miserable time for all involved. If you pick one way to wrap, and stick with it, the problems should be enormously reduced. I have no real-world experience with Shiboken (it's a bit too new, and I hardly ever do GUI apps these days any more... my world's all web app!-), but have used SIP in this role in the past (way back before it was decently documented -- these days it seems to me that it's splendidly documented, and superficial perusal of Shiboken gives me the same impression) and I can recommend it highly (indeed if I could choose it would be an option probably preferable to SWIG even if no Qt code was involved in a project).