LINUX.ORG.RU

Релиз PyQt 5.0

 , ,


0

1

После долгого ожидания и многочисленных бета-версий вышла популярная привязка языка Python к библиотеке Qt.
PyQt5 не сохранила обратную совместимость с PyQt4, но принесла поддержку новых возможностей Qt5.

Краткий список изменений и отличий от предыдущей версии:

  • Поддержка Qt5. Теперь вы можете писать программы на python под новую версию Qt, используя все её возможности.
  • Поддерживается только Python 2.6 и выше (вплоть до 3.3).
  • PyQt5 не поддерживает никаких функций API, помеченных как устаревшие в Qt5.
  • GIL теперь освобождается только тогда, когда это необходимо.
  • Убран код вызова SIGNAL() и SLOT(). Возможно использование только API v2.
  • QtDeclarative удалён. На его замену предлагается использование QtQuick.
  • QtScript и QtScriptTools более не поддерживаются. На их замену предлагается QtQml.
  • QtXML не поддерживается, предлагается использование QXMLStreamReader / QXMLStreamWriter или встроенные средства питона.
  • Реализация QtOpenGL поддерживается только посредством трёх классов: QGLContext, QGLFormat и QGLWidget.

Подробный список изменений

>>> Подробности

★★★★

Проверено: maxcom ()

в Qt5 же ещё не везде новое API соединения

anonymous ()

А я смогу писать фронтенд на JS с бэкендом на питоне?

buddhist ★★★★★ ()

в PyQt потоки настоящие или питоновские, которые лочатся по GIL?

EugeneBas ★★ ()
Ответ на: комментарий от EugeneBas

в PyQt потоки настоящие или питоновские, которые лочатся по GIL?

вобще-то GIL не лочит потоки. GIL лочит именно Пайтоновские операции, а не потоки.

и откуда взялся этот миф про GIL. наверно его придумали те кто ненавидит Python :-) ..

user_id_68054 ★★★★★ ()
Ответ на: комментарий от user_id_68054

пайсайд закопан

кстате очень похоже на правду

Near Term Plans for PySide (March 26, 2013)

...

Further down the road (but not that far) is improving things at the C++ level and working on supporting qt5.

вобще-то GIL не лочит потоки. GIL лочит именно Пайтоновские операции, а не потоки.

В данном случае разница невелика. Разные нити не могут параллельно выполнять опкоды Питона, так что параллелизм возможен только за счет ввода-вывода.

tailgunner ★★★★★ ()
Ответ на: комментарий от tailgunner

В данном случае разница невелика.

ну да. не велика.. но всё же есть :-)

user_id_68054 ★★★★★ ()
Ответ на: комментарий от tailgunner

...working on supporting qt5.

так-то да... но медленно как-то :-)

а в репозиториях Fedora вообще нет пакета PySide (и кажется не предвидится).. я имею ввиду если не считать эту головную боль под названием Python-2.X:).

конечно проблемы Fedora не касаются команды PySide ... но для меня это какой-то тревожный знак относительно проекта PySide.. странно что не нашлось мэйнтейнера в таком большом сообществе как Fedora :-)

user_id_68054 ★★★★★ ()
Ответ на: комментарий от user_id_68054

Просто о закапывании говорить несколько преждевременно.

tailgunner ★★★★★ ()
Ответ на: комментарий от tailgunner

Просто о закапывании говорить несколько преждевременно.

ну я надеюсь что нет , что не закопан..

но страшно за судьбу всё же... :-) как то так выражусь

user_id_68054 ★★★★★ ()

как много людей использует такую привязку, и, главное, зачем это нужно?

azazello ★★★ ()
Ответ на: комментарий от EugeneBas

в PyQt потоки настоящие или питоновские, которые лочатся по GIL?

Для гуя это не принципиально.

Rodegast ★★★★★ ()
Ответ на: комментарий от Rodegast

Нагуя мне без гуя когда с гуем догуя

anonymous ()
Ответ на: комментарий от Rodegast

Но qt - это не обязательно гуй, суть в том, что я хочу писать на питоне с настоящими потоками, без лишней синхронизации, а так получается, что быстро написал, а потом долго ждешь результата, пока посчитается...

EugeneBas ★★ ()
Ответ на: комментарий от EugeneBas

Но qt - это не обязательно гуй

Кроме гуя, всё остальное есть в самом Питоне.

tailgunner ★★★★★ ()
Ответ на: комментарий от tailgunner

Закопать может не закопали. Но вся разработка ведётся втихую и в закрытую. Что они там делают и на каком они там этапе ответить никто не может. Это их серьёзный недостаток по сравнению с открытостью разработки PyQt

anonymoos ★★★★ ()
Ответ на: комментарий от azazello

Вполне достаточно. Особенно много поклонников среди людей, уже перешедших на python 3, для которого из лагеря gtk есть только GObject, для которого нет даже банальных бинарных сборок под все платформы. А про дизайнер я вообще молчу.
А на PyQt уже сейчас легко и просто можно писать гуёвый софт на python 3 и он будет отлично работать.

anonymoos ★★★★ ()
Последнее исправление: anonymoos (всего исправлений: 1)
Ответ на: комментарий от anonymoos

А на PyQt уже сейчас легко и просто можно писать гуёвый софт на python 3 и он будет отлично работать.

И будет под GPL. «Это их серьёзный недостаток» (ц)

tailgunner ★★★★★ ()
Ответ на: комментарий от tailgunner

GNU/Linux от него особо не страдает последние лет двадцать. Внутренний софт компании тоже.
А делать проприетарный закрытый софт на питоне, это как-то очень странно. У него байткод разбирается на раз-два

anonymoos ★★★★ ()
Ответ на: комментарий от anonymoos

GNU/Linux от него особо не страдает последние лет двадцать

GNU/Linux сейчас пишут корпорации, раньше - вольные разработчики. Ни те, ни другие не зависят от продаж софта.

байткод разбирается на раз-два

Нерелевантно.

tailgunner ★★★★★ ()
Ответ на: комментарий от tailgunner

Питон стал моим любимым языком программирования в том числе и потому, что всегда можно открыть программу и быстро что-то в ней поправить, без всяких перекомпиляций и пересборок.
Закрытая программа на питоне теряет для меня все свои плюсы. Не представляю где и кем она может быть востребована. Это же просто жирнота с кучей зависимостей.

anonymoos ★★★★ ()
Ответ на: комментарий от anonymoos

Закрытая программа на питоне теряет для меня все свои плюсы. Не представляю где и кем она может быть востребована.

Даже не знаю, что тебе сказать. Причем тут закрытость? Причеме тут сила твоего воображения?

Это же просто жирнота с кучей зависимостей.

И что? Моя любимая игрушка Blade of Darkness тащила внутри интерпретатор Python. «Жирнота» размером в несколько метров (и даже несколько десятков метров) - это уже много лет не жирнота.

tailgunner ★★★★★ ()
Ответ на: комментарий от tailgunner

Кроме гуя, всё остальное есть в самом Питоне.

сомневаюсь, что то, что написано на чистом питоне будет работать быстрее, чем то, что написано на плюсах

EugeneBas ★★ ()
Ответ на: комментарий от tailgunner

Моя любимая игрушка Blade of Darkness тащила внутри интерпретатор Python.

[offtop]кстати да, зачетное рубилово было[/offtop]

Boba_Fett ()
Ответ на: комментарий от tailgunner

Я не понял, я могу выполнять полностью независимые потоки питоновской программы на 6 ядрах? Если вместо одного потока обработки запущу 5? Будет все равно один работать?:

I-Love-Microsoft ★★★★★ ()
Ответ на: комментарий от I-Love-Microsoft

Я не понял, я могу выполнять полностью независимые потоки питоновской программы на 6 ядрах?

В CPython нет независимых нитей. Они настоящие нити ОС и блабла, но повторюсь: параллельное выполнение опкодов Python VM невозможно (в CPython). Если тебе нужно Ъ-параллельное исполнение Python-кода (зачем, кстати?), то выход на сегодня один - multiprocessing.

tailgunner ★★★★★ ()
Последнее исправление: tailgunner (всего исправлений: 1)
Ответ на: комментарий от EugeneBas

сомневаюсь, что то, что написано на чистом питоне будет работать быстрее, чем то, что написано на плюсах

Не будет. Но зато писать быстрее и проще, а скорость... какие задачи? Для числодробилки numpy дает вполне нормальную скорость.

tailgunner ★★★★★ ()
Последнее исправление: tailgunner (всего исправлений: 1)
Ответ на: комментарий от tailgunner

Вы меня все запутали. Короче, я пишу на Qt5/C++ и делаю потоки через QThread. Завтра я беру PyQt5/PySide+Qt5 и делаю тоже классы с QThread - оно так же параллельно работать будет? Или какие-то замуты меня ожидают?

Ну беру я multiprocessing и? Там всё хорошо? Я могу C-функции (нативные) вызывать из каждого из потоков?

I-Love-Microsoft ★★★★★ ()
Ответ на: комментарий от anonymoos

А так вот теперь, наверно, на чем Космонавт будет писать новый гуй Юнити)))

Twissel ★★★★★ ()
Ответ на: комментарий от I-Love-Microsoft

Вы меня все запутали.

Ну извини, я не могу объяснять проще %)

Завтра я беру PyQt5/PySide+Qt5 и делаю тоже классы с QThread

Питоновские классы, производные от QThread? O_o

оно так же параллельно работать будет?

Зависит от того, что ты в них исполняешь. Если Питон-код - нет, не так же.

Ну беру я multiprocessing и? Там всё хорошо?

ДА!!1

Я могу C-функции (нативные) вызывать из каждого из потоков?

Можешь.

tailgunner ★★★★★ ()
Ответ на: комментарий от EugeneBas

Билд-система - это просто запускалка компиляторов. Быстродействие собственно Питона там не играет роли.

tailgunner ★★★★★ ()
Ответ на: комментарий от tailgunner

еще как играет, билд система строит дерево зависимостей и прочухивает, что нужно строить и в каком порядке и вот мой опыт показывает, что делает она это крайне медленно. простой make пашет гораздо быстрее, но чертова политика начальства...(

EugeneBas ★★ ()
Ответ на: комментарий от EugeneBas

билд система строит дерево зависимостей и прочухивает, что нужно строить и в каком порядке и вот мой опыт показывает, что делает она это крайне медленно. простой make пашет гораздо быстрее

Я очень сильно подозреваю, что «простой make» работает гораздо быстрее только потому, что делает гораздо меньше. Скажем, у него деревья зависимостей не такие раскидистые или он полагается на даты вместо контрольных сумм.

tailgunner ★★★★★ ()
Ответ на: комментарий от tailgunner

Блин, я пытаюсь уловить глубинную суть проблемы GIL в случае PyQt5 и QThread (питоновских оберток над QThread http://pyqt.sourceforge.net/Docs/PyQt5/api/qthread.html).

Вот я беру PyQt5 и пишу обычную программу с QThread. Затем, через неделю, в этих QThread я вызываю C-шные функции для ускорения некоторых операций с помощью специально написанных модулей на языке Си. Какие проблемы ждут?

Второй вопрос - такие штуки типа PyPy работают с PyQt5?

Просто хочу перейти на разработку на более высокоуровневом языке с автоматическим управлением памятью типа Python не расставаясь с Qt5, а писать Си-модули для критичных операций - это упрощает подход к написанию нативного кода, и пытаюсь предварительно изучить проблемы и последствия прежде чем решиться.

Будь у Mono нормальные биндинги и интеграция Qt - я бы всё же перешел на Mono+C#+Qt. Просто Python мне как платформа больше нравится ибо может работать на экзотических архитектурах (которыми я активно пользуюсь) в виде простого интерпретатора байткода, а в Mono эту возможность убрали увы («We used to sugget porting the interpreter first, but since we no longer maintain the interpreter code, you should skip this step, the interpreter is most likely not compilable anymore, so go to the JIT porting section.») - большая ошибка команды Mono, получается что на процессорах типа Эльбрус или любой другой экзотике запустить программы уже будет невозможно.

I-Love-Microsoft ★★★★★ ()
Последнее исправление: I-Love-Microsoft (всего исправлений: 1)
Ответ на: комментарий от I-Love-Microsoft

Вот я беру PyQt5 и пишу обычную программу с QThread.

Я не знаю, что такое «обычная программа с QThread». Более того, я не понимаю, зачем использовать QThread в Python-программе.

такие штуки типа PyPy работают с PyQt5?

Нет.

получается что на процессорах типа Эльбрус или любой другой экзотике запустить программы уже будет невозможно.

Поверь мне, если ты попробуешь запустить твои Qt5-программы на Эльбрусе (неважно, Э-90микро или Э-3М), то... короче, ничего у тебя не получится.

tailgunner ★★★★★ ()
Ответ на: комментарий от tailgunner

Я не знаю, что такое «обычная программа с QThread». Более того, я не понимаю, зачем использовать QThread в Python-программе.

Хорошо, оставим QThread, я пишу на Python используя потоки из multiprocessing: какие ограничения???

Я могу вызывать из каждого потока функции из модуля-расширения на языке Си? И это будет работать параллельно?

Нет.

На сайте PyPy пишут что работает и с PySide и с PyQt4.

Поверь мне, если ты попробуешь запустить твои Qt5-программы на Эльбрусе (неважно, Э-90микро или Э-3М), то... короче, ничего у тебя не получится.

Ну хорошо, Qt4-программы там есть. Вероятно и PyQt4/PySide работать будут, т.к. Python в наличии.

I-Love-Microsoft ★★★★★ ()
Ответ на: комментарий от I-Love-Microsoft

оставим QThread, я пишу на Python используя потоки из multiprocessing: какие ограничения???

Разные адресные пространства.

Я могу вызывать из каждого потока функции из модуля-расширения на языке Си? И это будет работать параллельно?

В multiprocessing, как следует даже из названия, нет пото^Wнитей - вместо них процессы. Да, ты можешь вызывать Си-функции; да, они будут работать параллельно; нет, ты не сможешь использовать в этих функциях общую память (точнее, не сможешь это сделать по-простому).

На сайте PyPy пишут что работает и с PySide и с PyQt4.

Но ты спрашивал о PyQt5.

Qt4-программы там есть.

Я не уверен, что на Э-90микро есть Qt4; а на Э-3М1 она работает как... короче, глючит.

tailgunner ★★★★★ ()

А что такого хорошего написано на этом вашем сабже?

chromium ()
Ответ на: комментарий от anonymous

в Qt5 же ещё не везде новое API соединения

Ага. Я хоть и С++ использую, но недавно с удивлением обнаружил, что для QTimer::singleShot обязателен старый вариант (с использованием SLOT).

DarkEld3r ★★★★★ ()
Ответ на: комментарий от tailgunner

Ну спасибо! :) Теперь я всё на 100% понял окончательно. Что не общая память - ясно, это принципиально, но не беда.

I-Love-Microsoft ★★★★★ ()

Всё думаю, на чём писать Гуй, но Гуй пока не особо нужен. Для того, что потребно, хватает tkInter, особенно с темами.

Vudod ★★★★★ ()
Ответ на: комментарий от I-Love-Microsoft

Я могу вызывать из каждого потока функции из модуля-расширения на языке Си? И это будет работать параллельно?

Будешь в своих модулях освобождать GIL - будет работать параллельно.

anonymous ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.