Build error in Building PythonQtTests with r477
Dynamic Python binding for Qt Applications
Brought to you by:
florianlink,
marcusbarann
Hi!
i got an build error in Building PythonQtTests.cpp (coming from commit r473)
PythonQtTests.cpp: In member function ‘void PythonQtTestApi::initTestCase()’:
PythonQtTests.cpp:424:39: error: invalid new-expression of abstract class type ‘PythonQtTestApiHelper’
_helper = new PythonQtTestApiHelper();
^
In file included from PythonQtTests.cpp:42:0:
PythonQtTests.h:148:7: note: because the following virtual functions are pure within ‘PythonQtTestApiHelper’:
class PythonQtTestApiHelper : public QObject , public PythonQtImportFileInterface
^
In file included from PythonQtTests.h:48:0,
from PythonQtTests.cpp:42:
../src/PythonQtImportFileInterface.h:70:16: note: virtual bool PythonQtImportFileInterface::isEggArchive(const QString&)
virtual bool isEggArchive(const QString& filename) = 0;
Any help appreciated...
Here is a patch to fix compilation. I return false by default, seems currently not tested :-)
I fixed that on svn trunk. I should have compile/run the test on my last commit...
Did the test really run without errors? I got error in test exectuion in the importer test, where "bla" module is tried to imported (but not found). There i get a python exception that a function is returning NULL without error / exception set....
Yes, it works for me (I ran it with Python 3.6 and Qt 5.11 on vs2015).
On Fri 24. Aug 2018 at 10:31, Joerg Kreuzberger kreuzberger@users.sourceforge.net wrote:
ok, i still get these errors:
25: QDEBUG : PythonQtTestApi::testImporter() "No module named 'bla'"
25: QDEBUG : PythonQtTestApi::testImporter() "\n"
25: Fatal Python error: a function returned NULL without setting an error
25: QDEBUG : PythonQtTestApi::testImporter() "SystemError"
25: QDEBUG : PythonQtTestApi::testImporter() ": "
25: QDEBUG : PythonQtTestApi::testImporter() "<built-in 0x7ff3ef33fe98="" of="" object="" pythonqtimport.pythonqtimporter="" load_module="" at="" method=""> returned NULL without setting an error"</built-in>
I will check it again with a later release. My Config is Qt 5.9.5 Debug Linux gcc 5.4.0 on ubuntu
Ok, it works in release config, but not in debug
Same python error messages, but differnt handling of the return value
5: QDEBUG : PythonQtTestApi::testImporter() "No module named 'bla'"
25: QDEBUG : PythonQtTestApi::testImporter() "\n"
25: QDEBUG : PythonQtTestApi::testImporter() "Traceback (most recent call last):\n"
25: QDEBUG : PythonQtTestApi::testImporter() " File \"<string>\", line 1, in <module>\n"
25: QDEBUG : PythonQtTestApi::testImporter() " File \"<frozen importlib._bootstrap="">\", line 971, in _find_and_load\n"
25: QDEBUG : PythonQtTestApi::testImporter() " File \"<frozen importlib._bootstrap="">\", line 955, in _find_and_load_unlocked\n"
25: QDEBUG : PythonQtTestApi::testImporter() " File \"<frozen importlib._bootstrap="">\", line 656, in _load_unlocked\n"
25: QDEBUG : PythonQtTestApi::testImporter() " File \"<frozen importlib._bootstrap="">\", line 626, in _load_backward_compatible\n"
25: QDEBUG : PythonQtTestApi::testImporter() "SystemError"
25: QDEBUG : PythonQtTestApi::testImporter() ": "
25: QDEBUG : PythonQtTestApi::testImporter() "<built-in of="" object="" pythonqtimport.pythonqtimporter="" load_module="" at="" 0x7f45bc804288="" method=""> returned NULL without setting an error"
25: QDEBUG : PythonQtTestApi::testImporter() "\n"
25: PASS : PythonQtTestApi::testImporter()</built-in></frozen></frozen></frozen></frozen></module></string>
Hi!
Here is my patch for the Importer to fix the test in debug mode (python itself checks for debug and asserts in this case)
The patch is made against r493
Thanks, I merged your fix... I wonder if all places in the importer that return NULL should set an error. Starting with Python 3.6 we don't use the PythonQtImporter anymore in our product, we switched to using the default Python importer with some monkey patching to allow signed files.
I will keep it in for backward compatibility, but for Python 3.x I recommend not to use it, since it behaves substantially different from the Python 3 import mechanism (regarding pyc cache directories etc.).
I think they should do, cause python checks for nullptr from functions returning PyObject* and in debug do an assert.
We do also not use the importer, it was just for to get the test running...