Usando subclases Qt personalizadas en Python

Primero: soy nuevo en Qt y SWIG. Actualmente estoy leyendo la documentación de ambos, pero esta es una tarea que requiere mucho tiempo, así que estoy buscando algunos spoilers. Es bueno saber por adelantado si algo no funcionará.

Estoy intentando formular una architecture modular para algún software interno. Los componentes principales están en C ++ y se exponen a través de SWIG a Python para la experimentación y la creación rápida de prototipos de nuevos componentes. Parece que Qt tiene algunas clases que podría usar para evitar reinventar demasiado la rueda aquí, pero me preocupa cómo encajarán algunas de las brocas.

Específicamente, si creo algunas clases de C ++, tendré que exponerlas a través de SWIG. Algunas de estas clases probablemente son clases de Qt de subclase o, de lo contrario, tienen material Qt expuesto en sus interfaces públicas. Esto parece que podría plantear algunas complicaciones.

Ya hay dos interfaces para Qt en Python, PyQt y PySide. Probablemente usará PySide por razones de licencia. ¿Qué tan doloroso debería esperar que sea obtener una subclase personalizada envuelta en SWIG de una clase Qt para jugar bien con cualquiera de estos? ¿Qué complicaciones debo saber por adelantado?

PyQt expone el código C ++ a Python a través de SIP ; PySide lo hace a través de Shiboken . Ambos tienen aproximadamente las mismas capacidades que SWIG (excepto que solo son compatibles con “C ++ extendido a Python”, mientras que SWIG tiene back-ends para Ruby, Perl, Java, etc.). Ni SWIG ni SIP y Shiboken están diseñados para interoperar entre sí. No podría usar SWIG de manera conveniente para envolver ningún código con las extensiones C ++ que Qt requiere (para admitir señales y ranuras) y no tengo idea de qué peligros pueden esperarle al intentar interoperar envuelto en SIP (o envuelto en Shiboken) y SWIG Código envuelto.

¿Por qué, puedo preguntar, ha elegido usar dos formas separadas y equivalentes para envolver diferentes partes de su base de código de C ++ (Qt a través de SIP o Shiboken, todo lo demás a través de SWIG)? Si aún puede reconsiderar esta extraña decisión de diseño, le recomendaría encarecidamente que lo haga.

Si su elección de SWIG está tallada en piedra, predigo grandes problemas cada vez que esté envolviendo el código C ++ utilizando extensiones Qt (es decir, ranuras o señales) y un tiempo generalmente miserable para todos los involucrados. Si escoge una forma de envolver y se apega a ella, los problemas deberían reducirse enormemente. No tengo experiencia en el mundo real con Shiboken (es un poco demasiado nuevo, y casi nunca hago aplicaciones GUI en estos días … ¡la aplicación web de mi mundo! -), pero he usado SIP en este rol en el pasado ( Mucho antes de que se documentara decentemente, en estos días me parece que está espléndidamente documentado, y el examen superficial de Shiboken me da la misma impresión) y puedo recomendarlo altamente (de hecho, si pudiera elegir sería una opción probablemente preferible a SWIG, incluso si ningún código Qt estuvo involucrado en un proyecto).