Комментарии 14
Почему нельзя сразу импортировать весь модуль командой import?
Ведь "from * import *" только громоздкости добавляет.
PyQt просто ужасен в плане дизайна. Когда веб да и такие мастодонты от мира десктопа WPF/JavaFx предлагают нам разные сбалансированные подходы к разграничению кода и логики, как MVC/MVVM и ежи с ними, PyQt излевается на нас километрами нечистот декларативного спаггети когда. Кода который совершенно невозможно тестировать или поддерживать без мата. Вы скажете, но там же есть дизайнер формочек, да, но с ним тоже полно проблем и он совершенно не решает проблем с разграничением когда и логики.
Есть у них пояснение как пилить MV* на их фреймворке, но это просто испанский стыд по сравнению с mvvmFx от мира JavaFx.
Печально это все.
Я конечно не спец по биндингу для языка Python но сама технология Qt поддерживает дополнительный подход к разработке интерфейса в виде использования декларативного языка QML. На него хорошо ложится разделение логики и UI и возможно использование различных паттернов типа MVVM. Единственный недостаток который есть у этой технологии если нужен прям родной нативный UI из системы то она к сожалению такого не предоставляет.
Вы видимо очень плохо знакомы с python и PyQt в особенности, иначе я ваш коментарий объяснить не могу. Ненужно основываться в своих суждениях на вышеприведенный код, это всего лишь пример, а логику вы можете писать где угодно и как угодно не говоря уже о тестах. Вам никто не мешает разбить код на нужные вам архитектурные паттерны типа MVC самостоятельно, это займет минуту времени и придерживаться этой структуры своего приложения без строгого следования структуры приложения навязанного разработчиками библиотеки, python это не java в нем все делается быстро и просто, а QT очень мощная библиотека, которую используют крупные компании для своего софта например Autodesk, да даже KDE на нем написано. Для Java тоже есть обертка этой билиотеки Qt Jambi. Ну а для python PyQt это невероятно удобная и хорошая вещь по крайней мере гораздо лучше встроенной библиотеки Tkinter хотя и он для простых вещей очень даже ничего.
Вы видимо очень плохо знакомы с python и PyQt в особенности, иначе я ваш коментарий объяснить не могу.
Вы знаете, что бы оценить дизайн определенной библиотеки, совершенно не обязательно быть экскретом данной библиотеки, я бы даже сказал, наоборот. Если библиотека представляет вам 6 совершенно разных путей решения одной простой задачи, значит дизайн такой библиотеки отстой. Даже если ей пользуются массы крупных компаний.
Вам никто не мешает разбить код на нужные вам архитектурные паттерны типа MVC самостоятельно,
Подождите минутку, а почему это я должен пилить MVC велосипед поверх QT? Ладно если бы QT хоть как-то упрощала движение в сторону MVC, но нет, это просто ад. Вы говорите про минутку, хорошо, вот как вы можете запилить за минутку того чего нет? Этот факт известен.
и придерживаться этой структуры своего приложения без строгого
следования структуры приложения навязанного разработчиками библиотеки
Т.е. это мой MVC, и вообще я художник, я так вижу ...
python это не java в нем все делается быстро и просто
Быстро только мыши размножаются, херакс, херакс и в продакшен, нет спасибо не надо. На java тоже можно быстро и с каждой новой версией все проще и проще. А mypy и нативная нотация типов, это вообще создание еретиков которое делает python похожим на все эти противные, типизированные языки.
а QT очень мощная библиотека, которую используют крупные компании для
своего софта например Autodesk, да даже KDE на нем написано.
Мощная и невероятно запутанная, плохо спроектированная с точки зрения конечного пользования и с отвратной документацией, в которой черт ногу сломит. Ну Autodesk я бы не стал указывать как эталон, это скорее анти-эталон. KDE, не уверен, что они на питонах пишут, в любом случае надеюсь что они смогли победить плохой дизайн QT и организовать свою работу наилучшим, для себя, образом.
Вообще интересно было бы провести подсчет среди компаний использующих QT, что бы узнать сколько из них лабают адовый спагетти гавно-хардкор, сколько запиливают доморощенный MVC, а сколько пользуются другими, запиленными MV* парадигмами. Что-то мне подсказывает что первый вариант приходится на абсолютное большинство контор и опенсорс проектов, а жаль.
Если библиотека предоставляет несколько путей решения нетривиальных задач, значит, имея мозг, можно выбрать оптимальный из них в конкретном контексте.
Никто не должен пилить MV поверх Qt. В Qt реализован MVD подход, предполагающий отделение данных от их отображения и обработки.
Типизация позволяет в проекте больше хелловорда не запутаться во всех этих "правильных" либах питона, считающих своим долгом возвращать Any, чтобы ты лез в доку, и смотрел, что конкретно вернула тебе эта хренотень.
Не, ну по сравнению с питоновскими либами на десять функций Qt, конечно, очень сложен. Но этой штуке скоро тридцать лет, и на тех же плюсах можно писать код не беря вообще ничего, кроме стандартной либы и Qt. Но то, что кому-то лень потратить несколько часов и разобраться в объектной модели, не делает Qt плохой либой.
Мы на работе используем как mvd, так и mvc подходы. Но у нас много кастомных виджетов и отрисовки, поэтому специально под mvc ничего допиливать не пришлось.
В свое время у меня были проекты с двумя подсистемами ('Presentation' и 'Controller Presentation'), в которых я отдельно выделял саму форму (со всеми ее интерактивными методами работы кнопочек, полей ввода, переключателей....) и бизнес- логику ее работы. Не вижу никакой сложности сделать это самостоятельно. Со временем выпилил это деление, потому что у меня примитивный интерфейс, но это уже моя специфика.
А на мобилках Python всё ещё через боль и страдания. Особенно если нужны доп.модули
Не хватает сборки в бинарник. Под Windows, помню, была программа для этого. На других платформах не видел. Сборка в бинарник могла бы решить проблему с отсутствием подключаемых файлов. Просто, уже много раз сталкивался с проектами на python, которые не запускались без нужных библиотек.
PyQt6 — полное руководство для новичков