[PySide] Python bindings for Qt/C++ library (advice needed on best practices)

[info at mycontent.gr]

Hello Alexandru,

thank you for your reply, that clarifies things.

In the first scenario (abstraction layer using the STL):
- There is the added advantage that one could use SWIG to create 
bindings to multiple languages (e.g. R). This is the approach taken for 
example in a library like SuperElastix 
(https://github.com/SuperElastix/SimpleElastix), but this means that the 
entire library would essentially be rewritten to use STL containers and 
basic types.
- An obvious disadvantage is that one needs to constantly convert 
between QString and std::string, QList and std::vector, QMap and 
std::map... Apart from the fact that all this code will need to be 
maintained, have there been any benchmarks on the performance 
degradation incurred when doing these conversion? In fact, does anybody 
know of a library that has taken this approach ("Qt inside, STL to the 
outside world") ?

In the second scenario (Qt types used as arguments to the Python bindings)
- Creating bindings for another language such as R is no longer 
straightforward.
- It is indeed a deployment question, that can be solved with 
requirements.txt for PIP. For this reason, actually, it may be helpful 
to modularize the PySide2 bindings along the lines of Qt's modules. If 
all that's needed for a library are the Py bindings to basic QtCore 
objects, then it would be preferable to be able to include a dependency 
only these bindings (something like pip install PySide2QtCore). I saw on 
the blog that you are considering such a possibility, that's good to hear!
This scenario is the approach taken by the QGIS team, for example. 
Quoting from their website: "PyQGIS bindings depend on SIP and PyQt4. 
The reason for using SIP instead of more widely used SWIG is that the 
whole QGIS code depends on Qt libraries. Python bindings for Qt (PyQt) 
are done also using SIP and this allows seamless integration of PyQGIS 
with PyQt." (replace SIP with shiboken2 and PyQt with PySide2 and you 
have our scenario).

Any other pointers to real-life libraries that had to deal with these 
issues will be greatly appreciated.

thank you for your time

George




On 19/07/2018 09:56 πμ, Alexandru Croitor wrote:
> Hi,
>
> For 1) if the bindings for your library don't expose any Qt classes to Python, then yes, you don't need to ship the QtCore python module, etc. You do need QtCore and QtXmlPatterns for building and running shiboken though. But deployment wise, you will only need Qt libraries and libshiboken, and the generated module for your library. You won't need PySide2 libraries.
>
> For 2) it's more of a deployment question, which for now users have to figure out for themselves based on their use cases. PyInstaller helps in this respect. And if you plan to publish your bindings to PyPi, I suspect there is some way (requirements.txt or similar) to specify that the PySide2 package needs to be installed as well.
>> On 19. Jul 2018, at 02:10, info at mycontent.gr wrote:
>>
>> Dear all,
>>
>> first of all congratulations and thanks to the PySide2 team for a great project.
>>
>> After going through the blog post at http://blog.qt.io/blog/2018/05/31/write-python-bindings/ on creating Python bindings for a C++ library with Shiboken, a few questions arise when thinking about a bigger/real-life project. I suspect these questions will come up frequently as people try to build Python bindings for their projects, so I would like to volunteer to collect the answers that I hope to get from this mailing list into a tutorial-style document (if the team is interested in this!)
>>
>> Suppose that we have a Qt-based C++ library, for which we would like to create Python bindings.
>> Many library classes are subclasses of QObject. There are several methods accepting QString arguments and returning QLists, QHashes, QMaps, as well as pointers to the library’s objects.
>> Suppose that the library uses QtSql and QtXml (and many elements of QtCore) internally, but these objects need not be exposed to the user.
>> In most use cases, the users of the bindings will not need the Qt user interface classes, as they will be writing automation scripts. The library itself does not depend on QtGui, QtWidgets etc.
>>
>> What would be the best course of action:
>> 1. Write a thin interface layer to the library using only C++ primitives and STL types, like std::string, std::list, so that all interfaces that will be exposed to Python accept and return standard library constructs?
>> 2. Create Python bindings with Qt objects as arguments?
>>
>> In the first case, how can we keep the dependencies for library users to a minimum? QtCore, QtSql and QtXml are necessary for the functioning of the library, but the Python bindings of these Qt libraries, normally should not be necessary (is this correct?).
>> In the second case, how can we package the library in such a way that the required PySide2 dependencies are installed automatically (preferably using pip)? How can we keep the dependencies to a minimum?
>>
>>


---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus