Also, what's PySide/PySide2?
PyQt5 and Qt for Python is a 1-to-1 binding to the original Qt and their APIs are almost identical, so you should be able to switch to Qt for Python quite easily when it is stable.
By the way, Qt for Python is re-branded from PySide2. They are the same.
Since then, bugs have been smashed, modules have been added and improvements have been made. I would recommend almost anyone to start developing with this right away and, like always, report bugs  and contribute improvements back to the project  (not on github).
I don't know much detail about PyQt5 vs PySide 2 but at least the overall logic should be the same.
In particular: https://github.com/DaveMDS/egitu
Scroll down to "python projects using EFL".
EFL has a number of questionable design choices, covered a little bit here: https://what.thedailywtf.com/topic/15001/enlightened .
[Py]Qt of course is cross-platform with the local look/feel.
In fact, when I tried variations of Qt for py, I just quit out of frustration with how things either didn’t work or didn’t work very fast, now I just stick with Tkinter.
To be honest most of the QT solutions for Python are pretty fidgety . The recent wxPython releases (4.x) work out of the box direct from PyPI, not too much to worry about licensing.
For Qt, it's... the licensing is usually just fine for people but it's complex enough to where things like maintaining your own fork (pretty easy in Python compared to C++) is not super easy. But there's decent Python support, so it's more "do you want to use Qt or wx". Both systems have good enough support.
It's most definitely not the most complicated thing, but when your processes are based off of BSD'd libraries, you gotta think a bit harder about Qt usage, if only for it falling outside the normal scope of things.