или бред сивой кобылы и лучше использовать C/C++ в связке.
Проблема в тех моментах, где от определенного функционала требуют скорость
примерно 0 раз из 1000
вообще никогда не видел такое
Зависит от того что ты понимаешь под "связкой"
Ну, если учитывать, что питон это (в основном) либо скрипты, либо веб, то ассемблер как будто бы некуда тут воткнуть
Бред сивой кобылы это постановка вопроса. Во-первых ассемблер не дает волшебной "производительности" в общем случае. Во-вторых разрабатывая код на Питоне в подавляющем большинстве случаев ты вряд ли когда-либо столкнешься с необходимостью писать код на ассемблере. Равно как и разрабатывая код на С или С++ тебе вряд ли понадобится писать код на ассемблере, за исключением очень специфических сценариев.
чисто к слову, я на выходных смотрел репы линуксовых дистрибутивов, и удивился, что куча тулзов пишутся на питоне) например вон линух минт https://linuxmint-developer-guide.readthedocs.io/en/latest/mint-tools.html
А что тебя удивляет? В линуксах нет такой проблемы с дистрибуцией, как на винде. Собирать GUI приложения тем более на Gtk вполне себе может быть удобно.
зато есть другие проблемы
я тоже был заложником мнения, что питон = вэб, скрипты итд. Оказалось там еще целое поле для применения)
ну вот хочешь ты без снапов иметь прогу в системе и чтобы она работала с системными завсиимостями, давай разбирайся со всеми дистрибутивами
Ну никто не мешает завендорить библиотеки \ тащить venv с зависимостями в пакете и не зависеть от системных пакетов
я скорее про то что разные дистрибутивы, разные подходы
Нууу... я бы не сказал что подходы радикально разные, разные системы сборки и доступные версии зависимостей, это да.
а зачем со всеми? собираешь или под тот линух, который сам используешь, или под корпоративный
то есть приложения для конечных юзеров мы даже не рассматриваем?
неа, я с таким почти не сталкивался в коммерческой разработке но насколько видел опенсурсное, оно собирается под убунту и в appimage (современные еще в snap или во flatpak) а мейнтейнеры, пользователи остальных дистрибутивов, если хотят видеть это приложение "нативно" в своем дистрибутиве, сами пишу ему спеки, собирают и его берут на дальнейшую поддержку разработчик же приложения, даже если и имеет нужную экспертизу в работе с пакетами под гайдлайгнам разных дистрибутивов (а это большая редкость) вряд ли сам захочет это делать, т.к. это долгая и нудная работа, которая только затормозит развитие проекта
Обсуждают сегодня