I intent to use Anaconda's Python in my Qt C++ application to call some scikit-learn algorithms from within my C++ code. For some reason I cannot figure out how to do the integration. I wonder if anybody knows a step by step procedure to do so.
If your C++ code works with Qt <= 5.9.7. (or more precisely Anaconda's current Qt version) you can include Python (in this case 3.6) by adding
INCLUDEPATH += /home/[username]/anaconda3/include/python3.6m
LIBS += -L/home/[username]/anaconda3/lib/ -lpython3.6m
to your .pro file.
If you need a Qt version which is higher than the one provided by Anaconda, have a look at my question here. Now you should be able to include the Python.h header in your application.
Remark: Keep in mind that Python provides its own signals and slots mechanism which can apparently clash with Qt's. That's why I added
CONFIG += no_keywords
to my pro file, and replaced all signals and slots occurrences like described here.
I am not sure this would work for you, but I'd look at this article. It provides at least a way to start a python interpreter from within the Qt application.
I think this might work, depending on the complexity of the thing.
You can find more on the PythonQt.
I don't know how well it will work with external packages though.
Otherwise, you could use PySide2, which allows you to create GUIs using Qt5 framework in python.
I hope it helps.
Related
What I wish to understand is what is good/bad practice, and why, when it comes to imports. What I want to understand is the agreed upon view by the community on the matter, if there's any one such in some PEP document or similar.
What I see normally is people have a python environment, use conda/pip to install packages and all that's needed to do in the code is to use "import X" (and variants). In my current understanding this is the right way to do things.
Whenever python interacts with C++ at my firm, though, it always ends up with the need to use sys.path and absolute imports (but we have some standardized paths to use as "base" and usually define relative paths based on those).
There are 2 major cases:
Python wrapper for C++ library (pybind/ctype/etc) - in this case the user python code must use sys.path to specify where the C++ library to import is.
A project that establish communications between python and C++ (say C++ server, python clients, TCP connections and flatbuffer serialization between the two) - Here the python code lives together with the C++ code, and if it some python files end up using sys.path to import python modules from the same project but that live in a different directory - Essentially we deploy the python together with the C++ through our C++ deployment procedure.
I am not fully sure if we can do something better for case #1, but case #2 seems quite unnecessary, and basically forced just by the choice to not deploy the python code through a python package manager. Choice ends up forcing us to use sys.path on both the library and user code.
This seems very bad to me as basically this way of doing things doesn't allow us to fully manage our python environments (since we have some libraries that we import even thought they are not technically installed in the environment), and that is probably why I have a negative view of using sys.path for imports. But I need to find if I'm right, and if so I need some official (or almost) documents to support my case if I'm to propose fixes to our procedures.
For your scenario 2, my understanding is you have some C++ and accompanying python in one place, and a separate python project wants to import that python.
Could you structure the imported python as a package and install it to your environment with pip install path/to/package? If it's a package that you'll continue to edit, you can add the -e flag to pip install so that when the package changes your imports get the latest code.
at work I have the task to convert a large library with Python 2.7 Code to Python 3.x.
This library contains a lot of scripts and extensions made with boost python for C++.
All of this is built with SCons which does not work with a Python 3.x interpreter, but now me and my supervisor want to know if there is a way around this.
The SConstruct file contains expressions with sys.version to determine the correct module-directories to import (numpy etc.). I do not know how to use SCons or the syntax, so I can not give a lot of information about this topic.
Can we use SCons to build Python 3 Code with the given extensions or do we have to wait until SCons is compatible with Python 3?
At the time of writing this, there are plans to support both Python 2.7 and 3.x in a single branch/version. Work on this feature has started, but it will take some more time to reach this goal.
So it looks as if your best bet would be to start right away. SCons itself should run fine under Python 2.7 for compiling the Boost extensions. The problem in your case are the added checks and detection mechanisms for deriving paths and module names from the version of the current Python interpreter.
Since you can't give any more detail about this process, my answer is somewhat vague here, sorry. In principle you'd have to find the place in the SConstructs/SConscripts where the version of the currently running Python interpreter is determined. Just hardcode this to the 3.x version that you have installed on the machine additionally, and keep your fingers crossed that the rest will work automatically.
Note how there is a clear separation here between "compiling code for a Python version" vs "compiling code under a Python version".
In general, a better understanding of SCons internal workings and basic principles might be helpful. If you find the time, check out the UserGuide ( http://scons.org/doc/production/HTML/scons-user.html ) or consult our user mailing list ( see http://scons.org/lists.php ) for larger questions and discussions.
I want to use Qt5 and QtQuick2 with a binding such as PyQt, but it seems the only builds available for PyQt are for Python 3.3. Are there any bindings I can use with Python 2.7?
I assume you're talking about binary installers for Windows. The maintainer of PyQt5 has made it very clear that he will not be providing them for PyQt5/Python2:
>>> Are there any Windows binary installers for PyQt5 and Python 2.7?
>>
>> No, and I don't intend to provide any.
>
> Thanks. Any particular reason?
Incompatibilities between dependencies and compiler versions - there would be no support for QtWebKit.
I'm trying to limit the total number of installer I maintain.
I'm doing my bit to encourage people to move to Py3.
PyQt5 for Py2 is fully supported, so there is nothing to stop anybody
else doing the work.
So you'd better have a very good reason for insisting on using Python2 with PyQt5, because you'll be commited to either maintaining Windows builds yourself, or relying on a third party to do it for you.
If you do a little web-searching, you will find a few binary installers out there, as well as instructions/tutorials for buidling them yourself. But I'm not going to endorse any of them here, because I haven't tried any of them myself (and have no intention of doing so).
Why can't I use other Qt series with different Python releases?
You can. If you have a specific version of Qt you would like to use, you can either download a matching PyQt version from Riverbank's download site or you can compile your own version of PyQt. I've had to build them from scratch a few times when the provided binaries didn't match the Qt/Python versions I wanted to use. It's a bit of a hassle to compile but it's definitely possible.
Also, note that the up-and-coming PySide library is an alternative Qt binding for Python that looks like it has a good chance of supplanting PyQt (due to looser licensing constraints).
Generally speaking, Qt Designer is an optional and independent component from PyQt. You can use it to create your .ui files but after that, it's up to the developer to determine how to use them... either generate Python code from them with pyuic4 or load them dynamically. As long as the format of the resulting .ui files are compatible with your version of PyQt, it shouldn't matter which Designer version you're using (though I would strongly recommend you use the version matching the Qt version PyQt is linked against).
I have read that it is possible to build GTK+ on MacOS X. I know that it's possible to create a bundle of a GTK+ application on MacOS. I also know that it's possible to create widgets that look sort of native. However, searching around I am not really clear on how to create a bundle that includes the native theme stuff, and uses Python rather than its own C main-point. There are also rumors that it's possible to build PyGTK, but it sounds like there might still be some wrinkles in that process.
However, there is no step-by-step guide that explains how one can set up an environment where an application might be run from Python source, then built and deployed in an app bundle. How can I go about doing that?
Native looking widgets is quite complicated.
There's a beginning of quartz engine (for theming) found here http://git.gnome.org/browse/gtk+/tree/gdk/quartz
For self-contained applications check out the newly released bundle on http://live.gnome.org/GTK%2B/OSX
I'm not sure if I'm grokking all the details of your question, but looking at your problem in general (how do I deploy a python app on mac), I'm inclined to say that the answer is py2app. Basically this will bundle a python interpreter and all relevant python files for you, and give you a scriptable system that you can use to add in whatever other resources/dependencies you need.
While it's not a guide solely targetted at python/GTK+/OS X, this post is a good, detailed description of someone else's attempt to do most of what you describe. Obviously, the app-specific stuff is going to vary.