Problem with "evalFile()"

[Malte Mueller]

Hi,

I am currently trying to get into the basics of PythonQt and encountered a strange error whilst trying out the examples:
whenever I try to evaluate a python file using the call mainModule.evalFile(":myfile.py"), nothing seems to happen, not even an error is thrown. However, removing the ":" from the file name (mainModule.evalFile("myfile.py")) results in an empty .pyc file being created and nothing else happening as well.
"evalScript()" works well.

I am on Windows 7, using Visual Studio 2013, Python 3.4. and Qt 5.4.

Any ideas?
Thanks in advance!

[Florian Link]

: refers to the Qt resource files, if you want to load files from the resources, you need to add them to the qrc file.
If you want to read a file from disk, I recommend that you use an absolute file path and no :.

[Malte Mueller]

using the absolute path behaves just like specifying the relative path: a zero-sized .pyc file is created and the program crashes.
I also tried "manual" compilation, and it yields a valid .pyc file.

Edit: after manually compiling a simplified myfile.py (not using PythonQt functionality nor the Pythonqt import) the evalFile() command is executed properly.
Yet that does not really help me, since this way I cannot share the Qt objects between python and c++...

[Florian Link]

Hm, maybe this is a Python 3 issue... I never tried parsing files with the Python 3 port, and I am not sure if any of the Python 3 users has.
Maybe you can step into evalFile with a debugger and see why the pyc file is not written correctly?

[Florian Link]

I don't have a Qt 5 / Python 3 setup at hand, since I switched to a new computer and we still use Qt 4.8 and Python 2.7 in our product.

[Alen.yang]

I still use Qt 4.8.6 and Python 2.7 ,But the call mainModule.evalFile(":myfile.py") is still unsuccessul,no error occur，I can not go next step.
could you help me please?

[Alen.yang]

bellow is the codes

            // init PythonQt and Python
     PythonQt::init();
      // get the __main__ python module
      PythonQtObjectPtr mainModule = PythonQt::self()->getMainModule();
      // evaluate a simple python script and receive the result a qvariant:
      //QVariant result = mainModule.evalScript("19*2+5", Py_eval_input);

      // create a small Qt GUI
      QVBoxLayout*  vbox = new QVBoxLayout;
      QGroupBox*    box  = new QGroupBox;
      QTextBrowser* browser = new QTextBrowser(box);
      QLineEdit*    edit = new QLineEdit(box);
      QPushButton*  button = new QPushButton(box);
      button->setObjectName("button1");
      edit->setObjectName("edit");
      browser->setObjectName("browser");
      vbox->addWidget(browser);
      vbox->addWidget(edit);
      vbox->addWidget(button);
      box->setLayout(vbox);
      // make the groupbox to the python under the name "box"
      mainModule.addObject("box", box);
    // evaluate the python script which is defined in the resources
      mainModule.evalFile(":GettingStarted.py");
      // define a python method that appends the passed text to the browser
      mainModule.evalScript("def appendText(text):\n  box.browser.append(text)");
      // shows how to call the method with a text that will be append to the browser
      mainModule.call("appendText", QVariantList() << "The ultimate answer is ");

[Florian Link]

I can not reproduce it, for me both files (inside resource and on disk) work well.
Maybe you need to understand the Qt Resource system better? If you do:

mainModule.evalFile(":myfile.py");

then you need to make sure to add myfile.py to the PyGettingStarted.qrc:

 <!DOCTYPE RCC><RCC version="1.0">
 <qresource>
 <file>GettingStarted.py</file>
 <file>myfile.py</file>
 </qresource>
 </RCC>

and re-run qmake to recreate the project and rebuild the project.
Otherwise myfile.py will not be part of the executable.

On the other hand, if you are using a file on disk:

mainModule.evalFile("myfile.py");

then you need to make sure that the current application working directory is where myfile.py is located when you run the executable, otherwise the file will not be found.
An alternative is to use an absolute path to a file, which does not depend on the current
working directory.

[Taehee Kim]

Hello Florian,

Are you also using Windows 7 and VS2013 to test? The other things about the environment doesn't match, but Win7 and VS2013 does, and I get the same behavior.

In my callstack, the last frame of PythonQt which causes the crash is:

void PythonQtImport::writeCompiledModule(PyCodeObject *co, const QString& filename, long mtime)

at the call of

  PyMarshal_WriteLongToFile(0L, fp, Py_MARSHAL_VERSION);

What I see is that it's using vc90's function to write the file, and it seems to fail at locking the file for writing.

---

I'm doing this instead to get around the issue:

    QFile script_file(script);
    if (!script_file.exists() || !script_file.open(QIODevice::ReadOnly)) {
        return false;
    }
    QString script_str = QString(script_file.readAll()).toLatin1();
    PyObject* code = Py_CompileString(
        script_str.toStdString().c_str(),
        script_file.fileName().toLatin1().constData(),
        Py_file_input
    );
    if (code == nullptr) {
        return false;
    }
    QVariant res = context.evalCode(code);

-Taehee

[Florian Link]

Yes I test on VS2013 and win 7... But it may be a Python 3 problem, I am not working with Python 3 yet.

[Taehee Kim]

Florian, I'm seeing the same problem on 2.7.9/10, so it's not only a Python3 problem.

What I do realize, though, is that I'm building PythonQt w/ 2.7.9, and it might've been picking up the binary for 2.7.10 during run-time. Could this have some impact?

[Vladimir Bondarenko]

Can confirm the problem under Win10/MinGW53/Py2.7, but for me it was opposite: happened with disk files and working perfectly with resource ones. Sadly, can't trace the bug, having big problems with debug build under MinGW.
BUT the workaround works! Thank you! Though explicit python library linking is a bit meh for my project.
Actually, first time I thought it's just that anti-MinGW python comunity, that refuses to add official MinGW support, but as I can see here the problem resides smw else, in the hell of vcXX libraries.