PySide availability for Python 3.5

[flutefreak7]

I've ran across a few loose threads of people mentioning PySide for Python 3.5. I'm assuming the greatest challenge is that Python 3.5 is compiled with Visual Studio 2015 with MSVCR 14, which means Qt and PySide must also be compiled with the same compiler. (Some of this might be Windows specific, but I mean for this issue to apply broadly to Python 3.5 compatibility on all major platforms...)

Since PyCharm 5 is out supporting 3.5, and Anaconda 2.4 is out supporting 3.5, I decided to try and make the switch yesterday. While many of the scientific ecosystem packages like numpy, scipy, pandas, and matplotlib were all ready for 3.5 (a boon in part thanks to the addition of the @ operator for matrix multiplication in numpy), PySide became the dependancy that prevented me from upgrading.

I discovered that while the official PyQt4 and PyQt5 downloads don't yet support Python 3.5, there are Windows binaries available through conda and at Christoph Gohlke's site. So it looks like there are Python 3.5 bindings for Qt, just not through PySide yet.

I completely understand that there isn't a lot of manpower available to tackle this, and not much benefit since not many people jump on the latest Python version right away. I just figured since many of the other ecosystems and libraries out there have updated to support 3.5 recently, that it's worth tracking PySide's progress towards Python 3.5 support.

I wish I was capable of helping with this issue, but I'm humbly out of my area of expertise with a task like this.

Thanks!

edit: spelling/wording

[ctismer]

Hi,

so what is your point, in the end?
Why do you urgently need to use 3.5, although you seem to know
about our limited resources?
Please tell me about any crucial feature that is
so important to you.

Did you for instance try pandas on Python 3.X at all? Did you even
find the obvious errors that make Pandas on 3.X hard to use?
Right now, Pandas is only completely working on 2.7 .

There is one single thing that is really urgent, because QtCorp's
support of Qt4 will end this year. We need to migrate to Qt5.

By now I still see no reason for upgrading to 3.5 but "convenience".

I wish I was capable of helping with this issue, but I'm humbly out of
my area of expertise with a task like this.

So how about installing 3.4 and using it as it is?
That would perfectly fit your incapability to help ;-)

As soon as we can support 3.5, we will do, but currently we can't.

cheers -- Chris

On 04/11/15 17:25, flutefreak7 wrote:

I've ran across a few loose threads of people mentioning PySide for
Python 3.5. I'm assuming the greatest challenge is that Python 3.5 is
compiled with Visual Studio 2015 with MSVCR 14, which means Qt and
PySide must also be compiled with the same compiler. (Some of this might
be Windows specific, but I mean for this issue to apply broadly to
Python 3.5 compatibility on all major platforms...)

Since PyCharm 5 is out supporting 3.5, and Anaconda 2.4 is out
supporting 3.5, I decided to try and make the switch yesterday. While
many of the scientific ecosystem packages like numpy, scipy, pandas, and
matplotlib were all ready for 3.5 (a boon in part thanks to the addition
of the |@| operator for matrix multiplication in numpy), PySide because
my week link that prevented me from upgrading.

I discovered that while the official PyQt4 and PyQt5 downloads don't yet
support Python 3.5, there are Windows binaries available through conda
and at Christoph Gohlke's site
http://www.lfd.uci.edu/%7Egohlke/pythonlibs/#pyqt4. So it looks like
there are Python 3.5 bindings for Qt, just through PySide yet.

I completely understand that there isn't a lot of manpower available to
tackle this, and not much benefit since not many people jump on the
latest Python version right away. I just figured since many of the other
ecosystems and libraries out there have updated to support 3.5 recently,
that it's worth tracking PySide's progress towards Python 3.5 support.

I wish I was capable of helping with this issue, but I'm humbly out of
my area of expertise with a task like this.

Thanks!

—
Reply to this email directly or view it on GitHub
#132.

Christian Tismer :^) [email protected]
Software Consulting : http://www.stackless.com/
Karl-Liebknecht-Str. 121 : https://github.com/PySide
14482 Potsdam : GPG key -> 0xFB7BEE0E
phone +49 173 24 18 776 fax +49 (30) 700143-0023

[DavidHowlett]

Please support Python 3.5. It is the only python I use right now. I have been trying to keep everything on my computer up to date.

[techtonik]

@DavidHowlett if you can persuade your company and it's clients who are relying on PySide and Python stack to support us and the awesome https://mingwpy.github.io/ project financially while we are working on it, that would be a great resolution to the problem.

[dickreuter]

Support for Python 3.5 would be amazing. If there's anything I can do to help I'm happy to contribute to the project. Surely there are not that many changes that are needed for that. If you can give me some hints where to start I'm happy to have a look.

[emmatyping]

@dickreuter what platform do you work on? If Windows, you'll have to compile Qt4 and PySide yourself, using VS 2015. You will need to disable the check for Python 3.5 too. On Linux you should only need to disable the check. Then you can start testing how things work.

[wasade]

The BSD-licensed open source projects I'm working on require Python 3.5 and we are unable to use Py 3.4. We are also unable to use PyQt due to its prohibitive licensing (as they removed the exceptions when Qt4 went to GPLv3). I greatly appreciate resource constraints particularly in OSS, but is there by chance an estimate on when we might expect Py3.5 support?

[techtonik]

I don't expect Py3.5 support as my job doesn't include PySide2 to cover time expenses, but I am free to switch the priorities.

[dickreuter]

This should definitely be a priority.

On 18 Sep 2016, at 11:47, anatoly techtonik [email protected] wrote:

I don't expect Py3.5 support as my job doesn't include PySide2 to cover time expenses, but I am free to switch the priorities.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.

[techtonik]

This should definitely be a priority.

Market says PyQt4.

[emmatyping]

So out of curiosity, I looked into compiling Qt 4.8.7 (the last supported version of Qt 4.x) with VS 2015, and IMO, it is more worth it to spend time porting to PySide2 and Qt5 (which supports Python 3.5) than to try to use a custom compiled Qt. The HEAD version of 4.8.7 does not compile by default on MSVC 2015. Even with a patch I found that fixed the first issue, I had further issues in linking. Sorry, but this just isn't likely to happen.

[krrr]

I have compiled and tested pyside 1.2.4 on Python3.5; both Qt and PySide need to be patched.
binary: https://github.com/krrr/PySide/releases

[emmatyping]

@krrr, as an aside unless you significantly changed things, you should be able to pip install wheel and build a wheel by running python setup.py bdist_wheel --cmake=blah --qmake=blahblah. Then people can just pip install the wheel file. Makes distribution easier.

[krrr]

@ethanhs link updated
I have some questions: how to use all CPU cores when building? set CL=/MPdidn't work
Is PySide1 discontinued?

[emmatyping]

@krrr PySide 1 is definitely no longer supported. Work is now going to have PySide work with Qt5. You can see the progress in the dev branch here.

Re building with all cores, this is a problem on Windows, you might be able to add the -jom switch, but I can't guarantee that that will work. If it does, it should build jom nmake files which will build in parallel.

[krrr]

@ethanhs jom works, but I have to modify setup.py, otherwise it fails and said it can't build shiboken doc. It's strange that I don't have to do this when using nmake.

By the way, can I compile only changed files after modifying type system xml?

[emmatyping]

@krrr not at the moment. Since you already have your own fork, you may want to look at this commit, which seems to add what you are looking for to PySide2

[vinlyx]

@krrr nice work~! Since some people (including me) do not have a complete toolchains to build from source, would you consider to release a wheel of win x64 version? Thanks~!

[krrr]

@ethanhs It's too difficult for me, I failed to figure out whether shiboken will regenerate all C++ files or not if only small part of the XML is modified. I gave up and almost forgot this...

@vinlyx I'm hit by a annoying bug (unmodifiable class variable), maybe I will do it later

[Jerakin]

@krrr If you are able to a mac binary would also be appreciated

[krrr]

@Jerakin I have no mac😳

[greipfrut]

@Jerakin try out this mac binary

[EvaSDK]

It would be nice to get the setup.py restriction lifted as this currently hinders the ability to install PySide even if no changes are needed to its codebase (at least for Linux). Ubuntu Xenial is shipping with 3.5, upcoming Debian Stretch is using 3.5 as well, Fedora has 3.6 available for f24 and f25, Arch Linux is using 3.6 for a few months, so for all these releases, PySide, while probably provided by distribution packages, cannot be installed by pip which is the goto tool for python developers. This also causes problems for people doing tests on platforms like Travis CI where the package cannot be installed for the matching python target.

All this said, if all is needed is a proper pull request from the community to get a release out, please list any requirements that would make it work as I guess simply removing the python version check will not be accepted.

[emmatyping]

@EvaSDK this was last left as basically a wontfix, as one needs to modify both Qt 4.8 and PySide sources to compile with the compiler used for Python 3.5 on Windows. Furthermore, Qt 4.8 is no longer supported, and PySide should not be used for new projects. PySide2, the next version, is the future of Python and Qt, and supports Python 3.5. You can find out more about it on the Qt Wiki.

However, since there is significant community interest in this, a good compromise might be to add an unsupported-python flag, that doesn't run this check.

[EvaSDK]

Referenced is an attempt to allow PySide to build on Linux platforms against python 3.5 and 3.6. I successfully generated a wheel out of this using the following docker image (riped off someone else work):

FROM ubuntu:16.04

RUN apt-get install -y build-essential git ccache cmake libxml2-dev libxslt1-dev && apt-get -y autoremove && apt-get -y clean
RUN apt-get install -y python-pip3 python3-dev && apt-get -y autoremove && apt-get -y clean
RUN apt-get install -y libqt4-dev libqtwebkit-dev && apt-get -y autoremove && apt-get -y clean

VOLUME ["src", "ccache"]

ENV CCACHE_DIR=/ccache PATH=/usr/lib/ccache:$PATH

# Set working directory
WORKDIR /src

# Build PySide wheel
ENTRYPOINT  \
            python3 setup.py \
                bdist_wheel \
                    --ignore-git \
                    --jobs=3

I will hopefully soon port my project off PySide to either PyQt5 or PySide2 due to numerous unresolved bugs in PySide that are driving me crazy.

[Torxed]

I get @ctismer's point way back in the day.
But I also laughed some what 2 years later almost to the day.

Because the default Python version now is actually 3.6.
And the "rush" of supporting 3.5 and now 3.6 is so that you don't become a obsolete package and let someone else take over your "market".

As of now, this is exactly what happens, either I have to install yet another binary on my computer, manage between version/environments.. or I'll have to rethink my strategy in terms of long term libraries that will continue to work throughout at least 2-5 minor releases.

Stating "what's the rush", and then later on being proven this is exactly why is kind of a bummer - as a user. Even tho I completely get the "understaffed" reason, it still feels odd to make this statement and this is the top result when googling "pyside python 3.6".

@EvaSDK

python2 setup.py

Are you sure you're building against python3?

[EvaSDK]

@Torxed, indeed, I failed at inline edit and this should be python3. It would fail to build due to missing headers.

[rth]

FWIW, pyside is packaged on the conda-forge channel up to Python 3.6,

conda install -c conda-forge pyside