Почему python не для настольных приложений?

Мало ли кто что тут сказал. Ты ещё на канал Рен-ТВ сошлись.

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

https://en.wikipedia.org/wiki/List_of_Python_software

Ну так всё кроме рендера и числодробилок там питон

reddit was originally written in Common Lisp, but was rewritten in Python in 2005[7]

Прикольно

написал плагин на питоне - записал всю софтину в список
круто, чо

https://jonlennartaasenden.wordpress.com/2014/11/06/famous-software-made-with...

И серьёзное GUI приложение на Python выглядит как говно

Qt из питона начинает вдруг как-то по другому выглядеть по сравнению с Qt из плюсов? Tk-то, понятно, выглядит как говно всегда и везде.

и постоянно срёт stack trace’ами

Каждый stack trace - это конкретная ошибка в коде, её можно найти и исправить. Это не свойство языка.

Нет никаких проблем с небольшими приложениями на питоне. Ключевое слово «небольшими».

Падает в рантайме из-за ошибок в именах переменных

Это свойство кода, а не языка. Есть flake8 и mypy которые уж имена переменных-то словят на раз-два, их использование практически ставит питон на одном уровне со статическими языками по возможностям отлова ошибок до runtume.

И, честно говоря, надо ещё поискать проект где возможны такие ошибки - это значит что там нет ни CI, ни тестов, ни сам автор его не тестирует, ни пользователей которые давно уже нашли бы эту ошибку у него нет. Если так, то увы. Но язык тут не при чём - аналогичный проект на Java падал бы с NPE, а на плюсах - с сегфолтом.

Отлаживать неудобно, особенно в связке с нативными библиотеками

А что вы собрались отлаживать? Мне за 5 лет продуктовой разработки ничего сверх встроенных стектрейсов и банального чтения кода не понадобилось.

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

Это бесспорно.

почему линукс не для игр?

4.2

Вот только в некоторых программах плагинов куда больше, чем скелета.

постоянно срёт stack trace’ами

А код на C и C++ срёт segmentation fault-ами

Как обычно - тормозит и жрёт память. Если для вас это не проблема (и, если вы пишете не только для себя, вам наплевать что это может быть проблемой для ваших пользователей), то никто не мешает использовать.

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

Потому GUI на чем угодно, числодробилку на C или C++, а всё остальное в плагины на Python-е. Учитывая огромное количество разработчиков на нём и простоту разработки есть шансы, что ты не один будешь над проектом пыхтеть.

Нет. GUI там не на Python.

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

Потому GUI на чем угодно, числодробилку на C или C++, а всё остальное в плагины на Python-е

Ну-у, это если есть плагины и если они не числодробилки, и не отменяет жора памяти и, в случае если ядно не на питоне, лишней зависимости. К слову, каждому приложению с использованием питона пришлось бы ещё пережить переход с 2 на 3, а если под него есть third party плагины это была бы неслабая боль.

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

Если ты пишешь десктопное приложение, к его разработке может присоединиться разработчик десктопных приложений (или разработчик в той области про которую приложение), а оный скорее всего не ограничен одним питоном. А «огромное количество» - это веб и ML макаки, которые не помогут никак.

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

https://itsfoss.com/free-linux-games/

Там нет GUI, там рендер и свои костыли для GUI

с другой - не вижу особых преимуществ по скорости разработки GUI приложений относительно тех же плюсов.

вот тоже самое, а то все говорят что питон хорош для прототипов.

Для прототипирования GUI нужно использовать, то где GUI задаётся декларативно html,xml или json:

• QML
• UWP
• JavaFX
• Electron
• другие декларативные тулкиты

а писать в GUI в коде примерно одинаково, что на python, что на С++.

если они не числодробилки

Что не мешатет делать их на питоне, а само ядро на чем угодно обернутое в питон, чтобы не тащить поддержку 100500 интерфейсов и оберток для каждого ЯП

вот тоже самое, а то все говорят что питон хорош для прототипов.

GUI пофиг где шлепать, его не руками писать в прототипе, да и в половине не прототипов тоже. А логику которую прототипируют куда быстрее на питоне писать, чем возиться с крестами или си.

Меня вполне по фичам устраивает veusz. Но это не к вопросу «профессиональности» софта, до которого мне как до звезды.

Есть tortoiseHg workbench, кому-то нравится Calibre. Кто-то наверняка использует ninja-ide, spyder или jupyter. Scons, если его можно считать «настольным».

Deluge, Exaile, Openshot, Gramps (прикольная штука), Gajim, Nikola (и другие генераторы статических сайтов), Meld (внезапно), Sphinx, ReText, Guake (частично), Wicd.

Portage ;)

это значит что там нет ни CI, ни тестов,

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

плюсах - с сегфолтом.

Нет, на плюсах это ошибка компиляции. А в питоне это ошибка времени исполнения.

А что вы собрались отлаживать? Мне за 5 лет продуктовой разработки ничего сверх встроенных стектрейсов и банального чтения кода не понадобилось.

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

Потому что есть другие языки, и у них есть свои любители. Ненавистники тоже есть. Да куда уж без них? Вообще, разнообразие - хорошая штука. Но если ты хочешь попробовать что-то написать на питоне, чтобы научиться программировать, например, десктопное приложение, то это похвальная идея.

Однако, если речь идет о высоконагруженном профессиональном десктопном софте (САПР там всякие), то тогда уже начнут играть такие вещи, насколько быстро грузится софт, насколько быстро отображает картинку, как реагирует на команды пользователя и так далее. И уже станет менее важно, что разработка кода стоит в разы дороже, ибо окупается сторицей. Здесь у питона много уже намного более сильных конкурентов.

И все эти костыли для GUI на C, а не на Python:

https://github.com/sobotka/blender/tree/master/source/blender/editors

Говорить что Blender на Python всё равно что говорить, что IDA тоже на Python.

Хейтить единственный пригодный инструмент непродуктивно.

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

Падает в рантайме из-за ошибок в именах переменных Это свойство кода, а не языка

Языка в том числе.

flake8 и mypy

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

Никакого уровня статческих языков не наблюдается и близко. Это лучше чем совсем ничего, но не сильно, ибо находит только самые тупые ошибки. За полгода, которые я этим пользуюсь, я продолбал гораздо больше времени на борьбу с отвратительно ложащейся на динамический язык системой аннотаций и mypy, чем получил профита. Если бы я потратил это время на пристальное вычитывание кода (как всегда и делал ранее) в несколько проходов и рефакторинг, пользы вышло бы гораздо больше. В статическом языке типы работают by design, и никакой борьбы с ними нет.

единственный

Да ну?

Просто не нужно тащить ни 100500 обёрток, ни одну для питона.

Ага и чтобы плагины было писать тяжелее, чем обычный софт. Или лучше, обмазаться сокетами. Чтобы всё на них было завязано, даже плагины. И с шифрованием трафика между ними, чтобы не подслушивал никто. Вот тогда заживём.

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

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

Нет, на плюсах это ошибка компиляции.

Я про общий случай. Не ошибка в имени переменной (как я уже показал, это странный пример высосанный из пальца) так ошибка выхода за границы буфера, или неинициализированная переменная, или use after free. Какие-то классы ошибок в питоне невозможны, какие-то в рантайме обрабатываются намного адекватнее. Заметь, я его не защищаю, я говорю что в этой плоскости он не отличается от других языков.

Много каких языков не подходят для настольных приложений. Поэтому настольные приложения писать перестали, остались браузеры с веб-приложениями в обёртке десктопных приложений.

Qutebrowser хороший пример. Но там только морда на Питоне.

Но ты же просто взял и смешал GUI-приложения на Python и популярные приложения на Python без GUI.

И лучше бы заменил SCons на Meson, Ninja и WAF.

Мало того, что ты обкладываешь аннотациями всё, что только можно, а оно всё равно тупое и не может понять какой тип там, где он легко выводится

Ну аннотации ничем не хуже типов в статически типизируемых языках, и вне сигнатур функций нужны очень редко, именно потому что mypy умный и всё замечательно выводит.

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

Никакого уровня статческих языков не наблюдается и близко. Это лучше чем совсем ничего, но не сильно, ибо находит только самые тупые ошибки. За полгода, которые я этим пользуюсь, я продолбал гораздо больше времени на борьбу с отвратительно ложащейся на динамический язык системой аннотаций и mypy, чем получил профита. Если бы я потратил это время на пристальное вычитывание кода (как всегда и делал ранее) в несколько проходов и рефакторинг, пользы вышло бы гораздо больше. В статическом языке типы работают by design, и никакой борьбы с ними нет.

Это какие-то очень странные заявления, похоже что ты ждёшь магии которой неоткуда взяться. «Динамику как динамику» нельзя статически проверить по определению - если она тебе нужна, не обессудь - будешь проверять всё в рантайме. Mypy никак не мешает её делать, и даже игноры для этого не нужны, тупо потому что есть Any. Но в общем случае код таки детерминирован и типы известны, и тут аннотации делают питон полностью эквивалентным по строгости статическим языкам (если указывать точные типы), или гибче, причём гибкость можно менять произвольно сообразно ситуации, используя более или менее абстрактные типы.

Я пользуюсь второй год и у меня только положительный опыт - о рантайм ошибках я вообще забыл, и не боюсь катить проект после серьёзного рефактиринга если mypy прошёл, тогда как раньше приходилось кропотливо гонять поект и вылавливать ошибки или писать горы тестов (сейчас такой необходимости не чувствуется и это освободило массу времени). Типы пишутся машинально и времени это не занимает. Динамические возможности где это нужно без проблем используются. Короче, питон здорового человека.

Нет там никакой простоты, если пишется не скрипт на сотню строк. Начнем с того, что питонист обязательно наговняет с архитектурой, намесит спагетти и запутается в собственном коде (более другие кадры просто не возьмут питон). А потом обделается при рефакторинге, и не сможет свою байду даже портировать на n+1 питон. Какие уж там контрибуторы, они просто не смогут въехать в говеную кодовую базу, где без пооллитра не разберешься, и IDE не помогает. Короче, все реально большие проекты на питоне скукожились и подыхают. Небольшие плагины, где строго один плагин = один разраб, еще возможно поддерживать, но и это боль.

Там большая часть к питону отношения не имеет.

практически ставит питон на одном уровне со статическими языками

Главное верить!

декларативно

QML

QML в том числе императивный.

Если тебя не выбешивает mypy, значит ты пишешь на питоне точно как на каком-нибудь го. Вопрос, зачем писать именно на питоне? Начальник заставляет?

разработчики Blender смотрят на тебя с недоумением А что бендер на питоне?

аннотации ничем не хуже типов в статически типизируемых языках

Хуже. Зачем заведомую чушь-то пороть? В статических языках система типов продумана как часть языка, а аннотации приделаны сбоку почти 20 лет спустя и никакого влияния на язык не оказали. Они бестолковы априори. Это очевидно как день.

именно потому что mypy умный и всё замечательно выводит

Ты или не в курсе или просто врёшь.

нельзя статически проверить по определению

И тут же ты противоречишь предыдущим заявлениям. Определись, работает оно или нет.

Оно убого by design, а ещё убого по факту. Тупит на ровнон месте, говорю же. Там где в статических языкая типы выводятся сами без малейших проблем, это позорище фейлит.

«Динамику как динамику» нельзя статически проверить по определению

Можно, переопределяя типы, только у mypy от этого пригорает. Не уверен (ибо не принципиально), но в PEP таких противопаказаний нет. И даже если есть, это тупняк ничем не обоснован, кроме сложностей реализации. Но это вообще не аргумент, не язык должен плясать от линтера, а линтер от языка.

Типы пишутся машинально и времени это не занимает

Типы в нормально типизированном языке с выведением типов да, а аннотации дофигище времени отнимают.

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

Раст нервно курит в сторонке, он просто скромничает. Ещё чуть чуть mypy допилят и можно супер безопасное микро-ядро на питоне запилить, а линукс выбросить.

mypy это имхо приговор питону. Всё, вокруг чего водили хороводы годами, в одночасье оказалось ненужным и вредным. Стоило только написать кривенький чекер. Ну сцуко, нельзя было сразу вкурить, что питон не годен для продакшна. Нет, надо было похайповать, навернуть горы говна, обделаться с ног до головы, и только спустя годы запилить убогий чекер, множащий на ноль все динамические достижения. Но и этот чекер идет на ура. А знаешь, что самое смешное: для рубей тоже недавно выкатили похожий чекер. То есть динамика обделалась по полной (или говнокодеры, которые не шмагли с нею совладать).

Хуже. Зачем заведомую чушь-то пороть? В статических языках система типов продумана как часть языка, а аннотации приделаны сбоку почти 20 лет спустя и никакого влияния на язык не оказали.

Ну кшна, они теперь куда не плюнь (всюду в стандартной библиотеке, и я уже даже не назову стороннего модуля где их нет), а mypy сам Гвидо пилит.

Они бестолковы априори. Это очевидно как день.

То что они не позволяют поднять производительность это конечно печально, но в остальном они семантически эквивалентны статической типизации.

Ты или не в курсе или просто врёшь.

Оно убого by design

а ещё убого по факту.

Тупит на ровнон месте, говорю же.

Там где в статических языкая типы выводятся сами без малейших проблем, это позорище фейлит.

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

Можно, переопределяя типы, только у mypy от этого пригорает

Что значит «переопределять типы»? Определи заодно тогда уж что у тебя за «динамика как динамика». Потому что у меня это, например, генерируемый в рантайме код. А если у тебя это всего лишь фиксированный набор типов вместо фиксированного типа, то для этого есть Union.

Типы в нормально типизированном языке с выведением типов да, а аннотации дофигище времени отнимают

Ты уже начал бредить. Вообще никакой разницы:

int f(int x)               # c/c++
fn f(x: i32) -> i32        # rust
def f(x: int) -> int       # python
public static int f(int x) # java

Потому что очень медленный даже на фоне Java.

Хотя бы памяти кушает меньше.

И серьёзное GUI приложение на Python выглядит как говно

GTK через pygobject выглядит неотличимо от напрямую через Си. Qt, вроде, тоже.

и постоянно срёт stack trace’ами.

Что именно?

Для прототипирования GUI – ок.

Тут похоже как с matrix-сервером synapse. Задумывалось по-быстрому как PoC, а получилось, что переписать с нуля ресурсов не хватило. По крайней мере мне кажется, что с Gajim такая же история была.

Вообще никакой разницы

Покажите аналог такого кода на питоне.