Personally I am unaware of such libraries. Consumers usually use Qt For Python, and only come around to interact when something is wrong, or when they don't know how to do something. IMO success stories are less frequently reported back, not due to not being successful, but rather if it works, nobody says anything.
More success feedback is obviously welcome. On 20. Jul 2018, at 01:49, [email protected]<mailto:[email protected]> wrote: 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, [email protected]<mailto:[email protected]> 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 _______________________________________________ PySide mailing list [email protected]<mailto:[email protected]> http://lists.qt-project.org/mailman/listinfo/pyside
_______________________________________________ PySide mailing list [email protected] http://lists.qt-project.org/mailman/listinfo/pyside
