PyQt czy PySide-którego użyć [zamknięty]

Jest też różnica w licencjonowaniu. PySide jest LGPL, podczas gdy PyQt jest GPL. To może mieć znaczenie, jeśli nie chcesz, aby twój projekt był opensource. Chociaż PyQt zawsze ma odpowiednią wersję dostępną za dość rozsądną cenę.

Wydaje mi się, że dokumentacja PySide jest bardziej intuicyjna. API, moim zdaniem jest nieco bardziej Pythoniczne, a szybkość poprawek jest dość imponująca w tej chwili.

PyQt ma zaletę obsługi Pythona 3 i Jest o wiele więcej dokumentacji/samouczków innych firm.

Niedawno przeportowałem znaczącą bazę kodu (ponad 8000 linii kodu) z PyQt do PySide.

W tej chwili powiedziałbym, że PyQt jest znacznie bardziej dojrzałym, wydajnym i stabilnym projektem. Trafiłem na kilka błędów w PySide i podejrzewam, że każdy duży projekt trafi w problemy. Powiedziawszy to, zgłosiłem błąd do projektu i został on naprawiony i w nowej wersji w ciągu kilku tygodni. Mam również problem, w którym aplikacja trwa około 15 sekund, aby zamknąć. Nie spędziłem jeszcze czasu, żeby dowiedzieć się dlaczego. Jednak to tylko kwestia czasu, zanim nie będzie powodów do wyboru PyQt zamiast PySide.

Jeśli zdecydujesz się na PyQt, upewnij się, że używasz API v2 przez cały czas. Jest to lepsze API i ułatwi przyszłe przejście na PySide. Również jeśli robisz port, po prostu postępuj zgodnie z wytycznymi na PySide wiki. Nawet dla aplikacji 8 + kloc składającej się z około 20 plików źródłowych zajęło to popołudnie.

Ważnym faktem jest to, że PyQt4 ma dwie wersje swoich API dla niektórych rzeczy. W wersji 1 elementy są takie rzeczy, jak za pomocą QString zamiast unicode, i QVariant (w zasadzie tylko wrapper, jak sądzę - nigdy nie zrobiłem nic, co go używa) zamiast owinięte. Wersja 2, która może być włączona w Pythonie 2 i jest włączona w Pythonie 3, jest o wiele lepsza (choć w wielu miejscach wciąż niepytoniczna - PySide też jest, ale robi się wyraźnie lepsza. Nadal istnieją pewne Niezgodności farmaceutyczne z nimi; PyQt4 ma QtCore.pyqt(Signal|Slot|Property), PySide ma QtCore.(Signal|Slot|Property).

Dla własnego projektu, zdecydowałem, że chcę wspierać oba bez zmian w kodzie. Wolę PySide, ale na Windowsie dystrybuuję z PyQt4, ponieważ obecnie jest on nieco mniejszy dla dystrybucji. Moim rozwiązaniem jest sprawdzenie pyqt4 i jeśli tam jest, Wstaw hak importu, aby przekierować import PyQt4 do PySide, lub jeśli nie, napraw PyQt4, aby działał tak, jak powinien.

Pliki używany:

• pyqt4pysideimporter.py
• zip_imp.py (dla obsługi py2exe)
• make_gui.py (mój skrypt do budowania .pliki ui i .pliki qrc z narzędziami pyside lub pyqt4 i naprawianie importu, aby był spójny; ankiety dla zmian plików i przebudowuje zmieniony - nic high tech jak inotify) {]}

Następnie po prostu import pyqt4pysideimporter i pyqt4pysideimporter.autoselect() (jak w main.py w tym repozytorium). A potem możesz po prostu import PyQt4.

Na bok: to było również stwierdził kilka dni temu na liście dyskusyjnej PySide, że planują wspierać Python 3 w pełni w ciągu najbliższych kilku miesięcy.

Chociaż mogą mieć podobny interfejs dla klas Qt/C++, ich interfejs dla makr Qt / C++, takich jak signal/slot / property, jest bardzo różny. Przenoszenie jednego do drugiego nie jest łatwym zadaniem. Lepiej byłoby podjąć właściwą decyzję na samym początku.

Poza różnicami gramatyczno-licencyjnymi, chcę tylko zwrócić uwagę na pewne braki PyQt w powiązaniu języka, które mogą być niezbędne do napisania projektu QML w Pythonie. Te różnice finalnie pchają mnie do PySide z PyQt.

• QmlRegisterType

  QmlRegisterType jest niezbędny do tworzenia wiązań runtime C++ z QML. W PySide jest częścią PySide.QtDeclarative. I to działa całkiem dobrze z Pythonem.

  W PyQt qmlRegisterType nie istnieje. I nie mogłem znaleźć alternatywnego podejścia. Wiem, że pewne proste zadanie można wykonać ustawiając kontekst QML. Ale jeśli naprawdę potrzebujesz wiązania runtime z qmlRegister i Q_INVOKABLE, myślę, że PySide jest jedynym wyborem w chwila.

• Shiboken VS SIP

  Oba mogą zawijać Qt / C++ do wtyczki Pythona. Dla Shibokena jest to prostsze i wymaga mniej kodowania. Wystarczy utworzyć typesystem xml zawierający nazwę klas , które chcesz wyeksportować i to wszystko. Shiboken nie wymaga dodatkowych ręcznych opisów dla struktury klas docelowych.

  Dla SIP, wymagałoby to więcej dodatkowego kodowania. Będziemy musieli utworzyć plik SIP, który prawie reimplements wszystko Nagłówek C++. Wymaga nie tylko nazwy klasy, ale także szczegółów, jakie metody mają klasy docelowe. Jeśli Klasa C++ jest w dobrym stanie używając Pimp i chcemy wyeksportować wszystkie metody wewnątrz niej, SIP powinien zapewnić sposób automatycznego wyeksportowania wszystkich metod klasy, czego w tej chwili nie może. Zwiększyłoby to również obciążenie dla zachowania spójności między nagłówkami SIP i C++.

  Ale muszę powiedzieć, że dokumentacja dla Shibokena na Qt wiki jest bardzo zła i wprowadzająca w błąd. Tworzenie wtyczki Pythona z Shiboken w systemie Windows niekoniecznie wymaga CMake w ogóle. generatorrunner również nie jest wymagany. Używam tylko skryptu cmd systemu windows, aby wywołać shiboken, i qmake pro do kompilacji wtyczki docelowej.

Mam 20-kilometrową aplikację Pythona, którą bezskutecznie próbowałem przekonwertować na PySide. Konwersja jest łatwa i większość funkcjonalności działa. Istnieje kilka metod, które nie są zaimplementowane, ponieważ są "przestarzałe" , więc musiałem je naprawić. Było OK. W systemie Windows, używając PySide-1.1.2, operator '= = ' nie jest zaimplementowany dla wielu obiektów Qt. Jednym z obejść jest stwierdzenie: "if id(item1) = = id(item2):". Inną obserwacją jest to, że PySide wydawał się zauważalnie wolniejszy. Nie izolowałem PySide jako przyczyna powolności, ale problem zniknął, gdy wróciłem do PyQt.

Wreszcie, jak na razie, Zestaw Android z PySide nie wydaje się gotowy na prime time.