silx
silx copied to clipboard
invalid result from Hdf5TreeModel.data()
With a fresh Conda install in a new env, aka
conda create -n silx -c conda-forge silx
conda activate silx
I get the following error when opening a valid HDF5 file:
ERROR:silx.gui.qt._qt:<class 'TypeError'> invalid result from Hdf5TreeModel.data(), unable to convert a Python 'Alignment' object to a C++ 'Qt::Alignment' instance
<repeated n times>
And a popup window:

$ conda list silx
# packages in environment at /home/debionne/miniconda3/envs/silx:
#
# Name Version Build Channel
silx 1.0.0 hd8ed1ab_1 conda-forge
silx-base 1.0.0 py310hb5077e9_1 conda-forge
$ conda list qt
# packages in environment at /home/debionne/miniconda3/envs/silx:
#
# Name Version Build Channel
pyqt 5.12.3 py310hff52083_8 conda-forge
pyqt-impl 5.12.3 py310h1f8e252_8 conda-forge
pyqt5-sip 4.19.18 py310h122e73d_8 conda-forge
pyqtchart 5.12 py310hfcd6d55_8 conda-forge
pyqtwebengine 5.12.1 py310hfcd6d55_8 conda-forge
qt 5.12.9 hda022c4_4 conda-forge
qtconsole 5.3.0 pyhd8ed1ab_0 conda-forge
qtconsole-base 5.3.0 pyhd8ed1ab_0 conda-forge
qtpy 2.0.1 pyhd8ed1ab_0 conda-forge
This seems to be related to the Qt binding for the latest version of Python. Pinning python to 3.7, aka:
conda create -n silx -c conda-forge python=3.7 silx
gives a working silx.
$ conda list qt
# packages in environment at /home/debionne/miniconda3/envs/silx:
#
# Name Version Build Channel
pyqt 5.12.3 py37h89c1867_8 conda-forge
pyqt-impl 5.12.3 py37hac37412_8 conda-forge
pyqt5-sip 4.19.18 py37hcd2ae1e_8 conda-forge
pyqtchart 5.12 py37he336c9b_8 conda-forge
pyqtwebengine 5.12.1 py37he336c9b_8 conda-forge
qt 5.12.9 hda022c4_4 conda-forge
qtconsole 5.3.0 pyhd8ed1ab_0 conda-forge
qtconsole-base 5.3.0 pyhd8ed1ab_0 conda-forge
qtpy 2.0.1 pyhd8ed1ab_0 conda-forge
Hi, Thanks for the report, we'll look into it, but it sounds like an issue in qt/pyqt. I also had troubles (other than with silx) making a conda environment with python3.10 and ended-up pinning to python3.9.
Closing, it seems to be a qt/pyqt issue. Please re-open if needed
This problem is still there.
ERROR:silx.gui.qt._qt:<class 'TypeError'> invalid result from Hdf5TreeModel.data(), unable to convert a Python 'Alignment' object to a C++ 'Qt::Alignment' instance
Any idea if this could be fixed somehow?
pyqt 5.12.3 py310hff52083_8 conda-forge
silx 1.0.0 hd8ed1ab_1 conda-forge
qt 5.12.9 h1304e3e_6 conda-forge
The root cause is:
>>> qt.QVariant(qt.Qt.AlignLeft | qt.Qt.AlignTop)
---------------------------------------------------------------------------
TypeError Traceback (most recent call last)
Cell In [5], line 1
----> 1 qt.QVariant(qt.Qt.AlignLeft | qt.Qt.AlignTop)
TypeError: unable to convert a Python 'Alignment' object to a C++ 'Qt::Alignment' instance
because the | operator returns a different type:
In [3]: type(qt.Qt.AlignLeft)
Out[3]: PyQt5.QtCore.Qt.AlignmentFlag
In [4]: type(qt.Qt.AlignLeft | qt.Qt.AlignTop)
Out[4]: PyQt5.QtCore.Qt.Alignment
I wonder why this does not occur for all platforms or for other installs + It occurs in 6 years old code...
| I wonder why this does not occur for all platforms or for other installs + It occurs in 6 years old code...
Some recent versions of PyQt have become very strict concerning types. They do not accepting integers where an enum was required.
I am almost sure the problem does not appear with PySide.
Yes it works with PySide2... and with latest PyQt5 (5.15.7)... but not with PyQt 5.12.3.
So no way to fix this PyQt version right?
There is a way: Fixing places using | for Qt flags throughout silx with: int(qt.Qt.AlignLeft | qt.Qt.AlignTop) or qt.Qt.AlignmentFlags(qt.Qt.AlignLeft | qt.Qt.AlignTop)... provided this works for all the other backends.
Can't you update pyqt? The fact that it used to work and works in newer versions really sounds like a pyqt issue.
This occurs with python3.10 and PyQt5 < 5.14.2 (tested with wheels).
Provided Python3.10 was released 4th of October 2021 and PyQt5 v5.14.2 3rd April 2020, it sound reasonable to me NOT to support older version of PyQt5 with Python3.10.
We can either leave it like this or raise an exception in this case (suggested by @vallsv), which is probably clearer.