mottosso / qt.py Goto Github PK

It would be good, for compatibility, for the PyQt4 import logic to also attempt to set the sip api version to 2 for at least QString and QVariant (setapi()). This will ensure that PyQt4 bindings behave the same way as PySide, when the helper library is hiding away the import details.

Caveat: It is possible for the setting of sip api v2 to fail, if another library was imported first, which uses PyQt4 and already locked sip into v1.

Wouldn't it be better to use the latest version?

https://github.com/mottosso/Qt.py/blob/master/.travis.yml#L8

Converting a project initially developed wih PyQt4, PyQt5 or PySide should be relatively straightforward and similar across projects. Let's collect our thoughts on some of the things to consider when heading down this route.

Qt.py conforms to the interface of PySide2, so if your code is already written for that you should only ever need to:

1. Search-and-replace PySide2 with Qt and you're done.

From PySide

This should be relatively straightforward as well.

1. Replace references to QtGui with QtWidgets apart from a few exceptions.

From PyQt5

Here I'd imagine:

1. Look into the different names for signals and properties, e.g. pyqtSignal

From PyQt4

Prepend this to the steps outlined for PyQt5

1. Convert code via pyqt4topyqt5

Finally, look towards CAVEATS.md for details and workarounds.

What's missing? Let's fill in the blanks.

I have a very large PySide application that has been developed for over 3 years. I've just started to convert it from PySide to PyQt4 and am using Qt.py to see how well it handles it. Surprisingly, I am hitting quite a decent size list of incompatibilities, so I thought I would list them here.

This list it not yet complete, asI have not finished fully testing every area of the app. I am a bit scared though, as Python is dynamic, that I could easily hit more of these during runtime if I don't manage to exercise every branch of the GUI code

QtCore.Slot - PySide allows for a result=None keyword param to set the return type. PyQt4 crashes

    QtCore.Slot(QtGui.QWidget, result=None)
TypeError: string or ASCII unicode expected not 'NoneType'

QAction.triggered signal requires a bool arg in PyQt4, while PySide cannot accept any arguments

# PySide
>>> a.triggered.emit()
>>> a.triggered.emit(True)
TypeError: triggered() only accept 0 arguments, 2 given!

# PyQt4
>>> a.triggered.emit()
TypeError: triggered(bool) has 1 argument(s) but 0 provided

>>> a.triggered.emit(True)  # is checked

QAbstractModel.createIndex(row, col, quint32)

In PySide, somehow the last argument (the id) is allowed to be negative and is maintained. While in PyQt4 it gets coerced into an undefined unsigned value.

# PySide
>>> idx = model.createIndex(0, 0, -1)
>>> print idx.internalId()
# -1

# PyQt4
>>> idx = model.createIndex(0, 0, -1)
>>> print idx.internalId()
#18446744073709551615

• Note - I had been using the id as an index into a list. But the unexpected return value from PyQt4 broke it by being invalid. The workaround was to always check that the returned id was between 0 and the max size I expect.

# PySide
>>> QtGui.QItemSelection.empty()

# PyQt4
>>> QtGui.QItemSelection.isEmpty()

However, they both do support the len(selection) operation

Closures

# valid in PySide
def someMethod(self):
    def _wrapper():
        self.runSomething("foo")

    someObject._callback = _wrapper
    someObject.someSignal.connect(_wrapper)

# In PyQt4 an exception is generated when the signal fires
    def _wrapper():
        self.runSomething("foo")
NameError: free variable 'self' referenced before assignment in enclosing scope

In PySide, the constructor for QtGui.QRegExpValidator() can just take a QRegExp instance, and that is all.

In PyQt4 you are required to pass some form of a parent argument, otherwise you get a TypeError:

QtGui.QRegExpValidator(regex, None)

I was just informed that the PySide2 development by the Qt Company is not being done over at the Github PySide2 repository. Instead it is being carried out here: http://wiki.qt.io/PySide2

I think it would be useful to include such info somewhere, probably in the README.

Basically, for each binding make sure it's easy to find the github repo ... or:

• source / binary distributions
• bug tracker
• mailing list (or equivalent)

Originally asked by Pierre Augeard:

What would be the wrapper around sip/shiboken?

For example:

• http://nathanhorne.com/pyqtpyside-wrap-instance/
• https://github.com/rgalanakis/practicalmayapython/blob/master/src/chapter5/qtshim.py

Goal

The available Qt bindings - PySide, PySide2, PyQt4 and PyQt5 - are automatically detected. In case two or more bindings are available and one if preferred, currently there is no way of specifying which to pick.

Enable some mechanism with which to specify up-front which bindings to use.

Motivation

Primarily intended for use in testing, where tests must be able to specify bindings with which to tests against, but could potentially be useful in an enterprise environment where multiple bindings must be present on the PYTHONPATH.

Implementation

Query the value of QT_PREFERRED_BINDING and throw an error is this binding doesn't exist.

Hi , is there any wrapped command for things like : pyside-rcc and pyside-uic , so does pick up the right one depending on the framework in use ?

For some reason, when you set e.g. sys.modules['Qt'] = PyQt5, the sys module cannot be used after this:

load_pyqt5()
print sys
>>> None

I was expecting:

load_pyqt5()
print sys
>>> <module 'sys' (built-in)>

Agreed.

This is what we have now:

"""Support Qt 4 and 5, PyQt and PySide"""
try:
    load_pyside2()
except ImportError:
    try:
        load_pyqt5()
    except ImportError:
        try:
            load_pyside()
        except ImportError:
            try:
                load_pyqt4()
            except:
                sys.stderr.write("Qt: Could not find "
                                 "appropriate bindings for Qt\n")

this module could benefit from adding support
for a code base that is in PySide 1 but installed version is pyside2,
as is the case of Maya 2017 for using legacy tools created for pyside1.

so basically doing a remap from qtwidgets back to qtgui.

Don't we want to import sys as _sys?

• https://github.com/spyder-ide/qtpy/tree/master/qtpy
• https://github.com/jupyter/qtconsole/blob/master/qtconsole/qt_loaders.py

For some reason, this doesn't return anything:

pip search Qt.py

Sorry, I wish I could be of more help. I'm unfamiliar with how to set up pip (although I'd like to learn).

Right now, the repo acts as a Python module:

~/code/github
❯ git clone https://github.com/mottosso/Qt.git
Cloning into 'Qt'...
remote: Counting objects: 39, done.
remote: Compressing objects: 100% (33/33), done.
remote: Total 39 (delta 14), reused 28 (delta 3), pack-reused 0
Unpacking objects: 100% (39/39), done.
Checking connectivity... done.

~/code/github
❯ python
Python 2.7.11 (default, Jan 22 2016, 08:29:18)
[GCC 4.2.1 Compatible Apple LLVM 7.0.2 (clang-700.1.81)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> from Qt import QtGui
Loaded PyQt5
>>>

Perhaps there should be a "Qt" folder in the github repo, which will be the Python module. Not sure how this is usually done and how it'll work with PyPi.

It seems in Qt5 webkit has been reshuffled as well as QtGui.
This means that QWebPage is no longer available under QtWebKit , but is now under QtWebKitWidgets.

PySide

From Qt.QtWebkit import QWebPage

PySide2

From Qt.QtWebKitWidgets import QWebPage

I'll createa branch with this fix and open a pull request.

L.

The guide here has a spelling error and more importantly provides an example that could be improved.

import sys
from Qt import QtWidgets
from Qt import load_ui


class Hello(QtWidgets.QWidget):
    def __init__(self):
        super(Hello, self).__init__()
        self.ui = load_ui('my_ui.ui')

app = QtWidgets.QApplication(sys.argv)
window = Hello()
window.ui.show()

sys.exit(app.exec_())

This could have been:

import sys
import Qt

app = QtWidgets.QApplication(sys.argv)
ui = Qt.load_ui("my.ui")
ui.show()
app.exec_()

Loading a standalone widget to the inside of another standalone widget doesn't make much sense to me.

What do you think of making the name more Python-specific?

I figure this would be the GitHub and PyPI name.

$ git clone https://github.com/mottosso/Qt.py
$ pip install Qt.py

But that we'd still import it as we do now.

import Qt

Importing the .Qt submodule of PyQt means "import all" which might give a performance hit, when one might only end up using QtWidgets (?)

Not sure what you meant here @mottosso

PEP08 mandates lower-case module names. But Qt bindings are traditionally mixedcase.

from qt import QtWidgets

# Or

from Qt import QtWidgets

Found some more cross-development tips here:

• https://github.com/PySide/pyside2/wiki/My_Practice_:_Porting_python_scripts_to_PySide2

Pasting them here in case they disappear. Will need formatting.

QHBoxLayout QVBoxLayout

Background:
Qt4 (PySide): QLayout::setAlignment(Qt::Alignment alignment)
http://doc.qt.io/qt-4.8/qlayout.html#setAlignment-2
Qt5 (PySide2): removed the above method
http://doc.qt.io/qt-5/qlayout.html#setAlignment
To upgrade to PySIde2, we have to make the following changes for
QHBoxLayout::setAlignment(Qt::Alignment alignment)
QVBoxLayout::setAlignment(Qt::Alignment alignment)

Qt4 (PySide):

layout = QHBoxLayout()
layout.setAlignment(Qt.AlignLeft)

Qt5(PySide2) : --solution

layout = QHBoxLayout()
QLayoutItem.setAlignment(layout, Qt.AlignLeft)

QHeaderView

Qt4 (PySide): http://doc.qt.io/qt-4.8/qheaderview.html

void    setResizeMode(ResizeMode mode);
void    setResizeMode(int logicalIndex, ResizeMode mode);

Qt5(PySide2) : http://doc.qt.io/qt-5/qheaderview.html

void    setSectionResizeMode(ResizeMode mode);
void    setSectionResizeMode(int logicalIndex, ResizeMode mode);

Solution:

pysideVersion = '-1'
try:
    import PySide
    pysideVersion = PySide.__version__
except ImportError:
    import PySide2
    pysideVersion = PySide2.__version__
if pysideVersion == '1.2.0':
    treeUI.header().setResizeMode(QHeaderView.Fixed)
    treeUI.header().setResizeMode(TREE_COLUMN_NAME, QHeaderView.Interactive)
    treeUI.header().setResizeMode(TREE_COLUMN_WEIGHT, QHeaderView.Stretch)
else:
    treeUI.header().setSectionResizeMode(QHeaderView.Fixed)
    treeUI.header().setSectionResizeMode(TREE_COLUMN_NAME, QHeaderView.Interactive)
    treeUI.header().setSectionResizeMode(TREE_COLUMN_WEIGHT, QHeaderView.Stretch)

QApplication.palette()

Background:
Qt4:
QPalette QApplication::palette()
http://doc.qt.io/qt-4.8/qapplication.html#palette

Qt5:
QPalette QGuiApplication::palette()
http://doc.qt.io/qt-5/qguiapplication.html#palette

Solution:
PySide(Qt4): palette = QApplication.palette()
PySide2 (Qt5): palette = QGuiApplication.palette()

Another workaround:

palette = self.palette()  # self is widget
# as you could also find palette() within QWidget class http://doc.qt.io/qt-5/qwidget.html   
# it works for both Qt4 and Qt5.

init() is being declared and immediately called, might as well not be a function?

Hi, I've been reading this article :
https://fredrikaverpil.github.io/2016/07/25/dealing-with-maya-2017-and-pyside2/

but when I try to import Qt into maya 2017 I get straight a :

File "....../site-packages/Qt.py", line 234, in _init
    raise ImportError("No Qt binding were found.")

do I have to set manually to PySide2 ?
should be able to automatically try them all and import ?
Am I missing something ? :)

Cheers.
L.

ps.
Note, PySide2 is available:

<module 'PySide2' from '/usr/autodesk/maya2017/lib/python2.7/site-packages/PySide2/__init__.py'>

Found this :https://wiki.qt.io/Transition_from_Qt_4.x_to_Qt5
about this issue.

This gets raised, when trying to use compiled widget (pyside-uic....), which has the retranslateUi() .

QApplication::translate("Href_Gui", "Text:", 0, QApplication::UnicodeUTF8)

QApplication::translate("Href_Gui", "Text:", 0)

Not really sure how to tackle this down.

Per the python mailing list discussion, add support for the 2nd argument to uic.loadUi

Here is an example using PyQt4

http://nullege.com/codes/search/PyQt4.uic.loadUi

Here is an example of an implementation for PySide that accepts the same arguments

https://gist.github.com/cpbotha/1b42a20c8f3eb9bb7cb8

I'm working on this now along with a sample Python script.

Goal

Check that all bindings provide identical members as PySide2; the reference binding.

Motivation

It has happened that one binding was missing access to certain classes that should have been available due to a typo or forgetfulness. A "one test to rule them all" for availability should iron these out.

Implementation

I'd imagine running a simple dir(PySide2.QtWidgets) and checking that against what's available elsewhere. It would be nice to also include argument signatures for these. Possibly that we can achieve this via the Python inspect module.

The number one goal is for each binding to provide the same members and argument signatures (differences break cross-binding compatibility). If we can also reach a state where they all provide everything that PySide2 has in an easy manner, then that would be great too, but it isn't as important and is unlikely to ever happen. Simply because some of the features provided are ad-hoc (due to trying to convert C++ methodologies to Python).

There should be some kind of error when there's no Qt binding available for loading.

Do we also wish to provide a facility to support differences between PySide/PyQt?

from Qt import QtCore
from Qt import QtWidgets
from Qt import __binding__
if __binding__.startswith('PySide'):
    from Qt import QtUiTools
    import pysideuic
elif __binding__.startswith('PyQt'):
    from Qt import uic
    import sip

I'm using the above frequently now, but it could have looked like this with the help of the Qt module:

from Qt import QtCore
from Qt import QtWidgets
from Qt import uic
from Qt import generator

In this case, perhaps uic and generator should be prefixed to stress they are custom wrappers.

Hi , is there any reason why there isn't a context manager for these two binding ?
Is anyone already looking on adding them ?
Asking as it would allow a more thoughtful testing.
Cheers.
L.

I just noticed this when importing PyQt5.

  File "/usr/local/lib/python2.7/site-packages/Qt.py", line 127, in <module>
    _init()
  File "/usr/local/lib/python2.7/site-packages/Qt.py", line 110, in _init
    sys.modules["Qt"] = available[preferred]()
  File "/usr/local/lib/python2.7/site-packages/Qt.py", line 35, in _pyqt5
    PyQt5.__binding_version__ = PyQt5.__version__
AttributeError: 'module' object has no attribute '__version__'

The only remaining problem is installing Python 3, and discovering an apt-get install of PyQt4.

• Travis log of problem
• .travis.yml at point of log

How can we install Python 3 and gain access to a system-wide install of PyQt4?

I noticed the README has a bunch of <br> tags which makes it really long (vertically). Just wondering if you intended to do that or if it was in error. The page becomes really long on a laptop but perhaps you felt readability was improved...?

Goal

Ensure caveats are actually caveats, from first writing through future changes.

Implementation

Automatically test documented caveats. We could have a look at running the examples we type into CAVEATS.md, and seeing whether they produce the expected output or throws the expected errors.

We'd have to be more careful in how we format it, but in general should be able to conform to the doc-test format.

Before

# PySide
>>> QtGui.QItemSelection.empty()

# PyQt4
>>> QtGui.QItemSelection.isEmpty()

After

# PySide
>>> from Qt import QtCore
>>> assert not hasattr(QtCore.QItemSelection, "isEmpty")
>>> assert hasattr(QtCore.QItemSelection, "empty")

# PyQt4
>>> from Qt import QtCore
>>> assert hasattr(QtCore.QItemSelection, "isEmpty")
>>> assert not hasattr(QtCore.QItemSelection, "empty")

Where each block is run, like other tests, in an independent process, using the binding specified on the first line.

In tests.py, I find the clean function a bit confusing...

Some points:

• Python does not support unloading modules
• Nose has this --with-isolation option, which does its best to isolate each test function.
• Currently, sys.modules.pop() is being used to "clean out" modules, but it doesn't actually clean out modules imported by the module you're popping.

If we just disregard that Python can't "unimport" modules and see how far we can push it... and skip --with-isolation since we might not want to isolate all functions –– shouldn't this be a more reliable cleaning function?

import os
import sys
import imp
import contextlib

from nose.tools import (
    with_setup,
    assert_raises,
)

_modules = sys.modules.copy()

def clean():
    """Provide clean working environment"""
    os.environ.pop("QT_PREFERRED_BINDING", None)
    modules_to_delete = list(set(sys.modules) - set(_modules))
    for module in modules_to_delete:
        sys.modules.pop(module)  # or "del sys.modules[module]"

Right now, even if you pop Qt, the modules imported by Qt aren't popped.

Also, with nose, we can create a tests folder (rather than the tests.py file), and inside it put several python scripts prefixed with test_ and nose will run all of them.

@mottosso what do you think about this?

Should Qt.py enforce/encourage portability? That is, should Qt.py try and prevent a user from using functionality found only in a specific binding, so that any code written with it is guaranteed to run on any other binding?

It's more or less a road in the fork between being a helper library or a complete framework.

Scenario A - Yes portability

>>> from Qt import QtCore
>>> signal = QtCore.pyqtSignal()
AttributeError: 'module' object has no attribute 'pyqtSignal'

Scenario B - No portability

>>> from Qt import QtCore
>>> signal = QtCore.pyqtSignal()
>>> signal2 = QtCore.Signal()
>>> from PyQt4 import QtCore
>>> signal3 = QtCore.pyqtSignal()

Implementation

We could achieve this by simply removing the redirected members.

PyQt4.QtCore.Signal = PyQt4.QtCore.pyqtSignal
del(PyQt4.QtCore.pyqtSignal)

However the problem is that this affects the PyQt4 module globally; meaning that if the user is running another application using PyQt4, it would break.

We could work around this by, rather than redirecting Qt.py to its nearest binding..

>>> import Qt
>>> print(Qt)
<module 'PyQt4' from '/usr/lib/python2.7/dist-packages/PyQt4/__init__.pyc'>

..we re-define each member..

>>> from Qt import QtCore
>>> print(QtCore)
<module 'Qt.QtCore' from '/usr/lib/python2.7/dist-packages/Qt.pyc'>

But the problem with that is (1) we would have to redefine every possible member of Qt which might be difficult and (2) because of (1) we would lose the current simplicity of Qt.py.

Discussion

If we choose to enforce portability, we'll have to consider the consequences and find an elegant way in which to implement it. If we chose not to, we should consistently ensure that Qt.py can be used alongside any particular binding.

An alternative approach might be to instead have a separate tool check for used features only found in any one binding?

# psuedo
# validate_portability.py
import PySide
import PyQt4

unique = set(all_pyside).intersect(set(all_pyqt4))

with open("mycode.py") as f:
  used_members = parse(f)
  for member in used_members:
    if member in unique:
      warn("%s is not portable!" % member)

Qt.py wants to replace itself with the resolved Qt bindings, by updating sys.modules. But it uses a hard-coded "Qt" string instead of __name__. This causes it not to work in my case where I am currently vendoring the Qt.py dependency into my project.

My import path looks something like this:

from project.packages import Qt

I had to update the locations that did this:

sys.modules["Qt"] = available[preferred]()

With

sys.modules["Qt"] = available[preferred]()
sys.modules[__name__] = sys.modules["Qt"]

pip install -U Qt.py returns version 0.2.2 for me (although 0.2.3 is available).

I'm very unfamiliar with how pip works and I've never distributed anything using it.

Do you have to perform any manual labour in order to get the newer 0.2.3 out onto PyPi?
I was under the impression that the setup.py was supposed to handle that?

I had to curl down the newest Qt.py from the github repo today since I wasn't able to fetch it via pip.

After having spent some time trying to get around the various differences in the framework, has become pretty clear to me, that all these in place replacements (still many to come I fear), might bring soon the code to a point where is going to be hard to maintain, especially if many other contributors are coming in.

Here an idea on how the code could be reorganised :

├── docs
│   └── source
├── setup.py
├── source
│   └── Qt
│       ├── __init__.py
│       └── bindings
│           ├── __init__.py
│           ├── _pyqt4_.py
│           ├── _pyqt5_.py
│           ├── _pyside2_.py
│           └── _pyside_.py
└── tests
    ├── test_pyside2.py
    ├── test_pyside.py
    ├── test_qt4.py
    └── test_qt5.py

Any thought on this ?
Cheers.

I believe we should create a docstring for _init() and explain what happens at sys.modules["Qt"] = binding().

For example:

def _init():
    """Try loading each binding in turn

    Please note: the entire Qt module is replaced with this code:
        sys.modules["Qt"] = binding()
    This means no functions or variables can be called after this has
    executed.
    """

What do you think @mottosso?

I didn't want to remove code which I thought was redundant before checking with you (@mottosso) first. What do you think?

When you import Qt you don't want stuff printed, I think.

Goal

Enable the end-user to exclude specific bindings from being made available, even though they are on PYTHONPATH.

Motivation

In some circumstances, only some bindings can reasonable be expected to exist. For example, in Autodesk Maya, only bindings for Qt 4 are possible and attempting to use Qt 5 may cause a crash.

Implementation

Alongside QT_PREFERRED_BINDING we'll make a QT_EXCLUDE_BINDING.

$ export QT_EXCLUDE_BINDING=PySide2:PyQt5

Question is whether to make it plural, as it's mean for multiple values, or singular to align with the other environment variable. Which is easier to remember, and which is easier understood?

As mentioned here.

Example:

>>> from Qt import load_ui
>>> class MyWindow(QtWidgets.QWidget):
...    def __init__(self, parent=None):
...        fname = 'my_ui.ui'
...        load_ui(fname, self)
>>> window = MyWindow()

These attributes currently do not exist on the Qt object, which are mentioned in the README:

# Reference to version of Qt, such as Qt 5.6.1
print Qt.__qtVersion__
# Reference to version of binding, such as PySide 1.2.6
print Qt.__bindingVersion__
# Version of this project
print Qt.__version__

pypi/Qt still exists, installed it by mistake today.

@mottosso can you remove that so it won't get confused with pypi/Qt.py?

Just popped over by chance.
Did anyone has been looking into it yet ?

https://github.com/spyder-ide/qtpy

Hi Marcus, trying now to port some complex stuff on Qt.py, but started hitting some issues:

from Qt.QtGui import QSortFilterProxyModel
ImportError: cannot import name QSortFilterProxyModel

any idea ?
Cheers.

p.s

from PySide.QtGui import QSortFilterProxyModel
print QSortFilterProxyModel
>> <type 'PySide.QtGui.QSortFilterProxyModel'>

print Qt
<module 'PyQt5' from '/usr/lib64/python2.7/site-packages/PyQt5/__init__.pyc'>

I'll try forcing on PySide

Goal

Enable testing of Qt.py with Pyside2 and PyQt5.

Motivation

At the moment, testing only happens with PySide and PyQt4, but the codebase and tests remain open for expansion towards bindings for Qt 5. The reason they haven't yet seen the day of light has been due to difficulties in installing each binding in an efficient manner.

PyQt4 and PySide both have pre-compiled counterparts that take a matter of seconds to install, whereas Qt 5 bindings are more complex, especially PySide2, requiring manual compilation. (On Python < 3.5).

Docker has always been an option, but the problem has been losing out on being able to concurrently run tests, one build per version of Python. But this technique should enable greater concurrency, and greater distribution of tasks with one build per version of Python and binding.

Implementation

The idea is simple. Utilise the build matrix functionality to provide many identical environments with varying environment variables. The environment variables can then be used to programatically select an appropriate Docker image.

I'm finishing up some stuff and just quickly jotting this down so I can adress this later on...

QItemSelection

• PyQt4: QtGui.QItemSelection
• PySide: QtGui.QItemSelection
• PyQt5: QtCore.QItemSelection
• PySide2: where are the docs?
• Qt5: QtCore.QItemSelection

QItemSelectionModel

• PyQt4: QtGui.QItemSelectionModel
• PySide: QtGui.QItemSelectionModel
• PyQt5: QtCore.QItemSelectionModel
• PySide2: where are the docs?
• Qt5: QtCore.QItemSelectionModel

So it seems we should be able to do:

def _pyqt4():
    # Remap
    PyQt4.QtCore.QItemSelection = PyQt4.QtGui.QItemSelection
    PyQt4.QtCore.QItemSelectionModel = PyQt4.QtGui.QItemSelectionModel

def _pyside():
    # Remap
    PySide.QtCore.QItemSelection = PySide.QtGui.QItemSelection
    PySide.QtCore.QItemSelectionModel = PySide.QtGui.QItemSelectionModel

Qt.__qt_version__ is currently showing the PyQt version, when it should be showing the Qt version.

• code