Руководящий совет проекта Python объявил о намерении утвердить предложение по расширению языка Python PEP-0703, в котором определяется добавление режима сборки CPython без глобальной блокировки интерпретатора (GIL, Global Interpreter Lock). В качестве вероятного срока реализации PEP-0703 упоминается выпуск Python 3.13, намеченный на осень следующего года...Подробнее: https://www.opennet.dev/opennews/art.shtml?num=59518
Избавиться от питона во много раз проще. Более того, не начинать его учить или использовать - ещё проще.
Да, 20 лет нямкали коричневую субстанцию с gil и ещё 5 или 10 - без разницы.
>Избавиться от питона во много раз проще.Нет, если у тебя вся инфраструктура на нём.
>Более того, не начинать его учить или использовать - ещё проще.
С нуля Ансибл написать? Или библиотеки для ИИ?
Смех, у кого то вся инфраструктура на Коболе это не помешало всем отказаться от Кобола.
Помешало. Кобол до сих пор используется.
Да продолжает, только эти компании не могут найти себе программистов от слова ваще.
Могут и находят. Им дешевле заплатить 1.5 зарплаты от рыночной, чем менять всё написанное
А ты смешной на почитай что в реальном мире происходит https://www.cnews.ru/news/top/2020-04-07_ssha_izza_koronavir...
Я читал подобные статьи. И уже написал выше, как обходят этот дефицит - просто предлагают повышенную зарплату. Люди находятся.
Лол оно так не обходится. Инфраструктура Кобола от этого не расширяется. Новых внедрений Кобола не появляется. Залить деньгами это сказка из телевизора. Перестань рассказывать сказки.
Если у кого-то есть готовая инфраструктура и её обновление обойдётся, например, в 750 млн. долларов и займёт, как минимум, 5 лет (как указано в статье, которую ты сам привёл), что проще (дешевле): найти человека (людей) которым платить 1.5-2 коэффициента от рынка, или заниматься миграцией на что-то другое с плохо предсказуемым результатом?Ты, по всей видимости, в таких проектах никогда не принимал участия, раз для тебя это "сказки". А я - принимал. Это огромный труд и огромные же затраты. Причём затраты не только на ПО, а ещё на переобучение людей, изменение бизнес-процессов.
Как поступать в таких случаях правильно? Если есть такая возможность - менять частями. Но даже при таком подходе куча проблем гарантирована (обмен данными между разными системами).
Если есть так много людей на Коболе зачем менять систему? Ой так потому что нет никаких людей. Ни за какие деньги.
Где я сказал, что есть "много людей"? Я сказал, что люди находятся. Это проблема, и никто её не отрицает. Просто масштаб проблем разный: найти кого-то на улице и обучить за десятки (даже сотни тысяч), или за сотни миллионов менять систему.
Это же и есть отказ от Кобола.
Если бы ВНИМАТЕЛЬНО и ВДУМЧИВО читал с чего всё началось, вообще бы не начинал эту ветку. Давай я тебе освежу память.>Избавиться от питона во много раз проще.
Нет, если у тебя вся инфраструктура на нём.
Как в итоге выяснилось на примере Кобола - менять инфраструктуру - это отнюдь не тривиальный процесс. Да? Ведь именно об этом я и говорил.
Ты сейчас жутко удивишься, но проекты бывают не только легаси, но и сейчас набери воздуха в грудь, НОВЫЕ. И ты не поверишь все кто могли позволить себе использовать Кобол в новом проекте от него отказались! Вот это номер! Как так!
>Новых внедрений Кобола не появляется.Вы будете смеяться,но есть порт Кобола на net платформу.
https://www.c-sharpcorner.com/article/cobol-for-microsoft-net/Не спорю что это для портирования старых проектов,но смотрится забавно...
Более того, Cobol'у учат и новичков. И находятся те, кто учится - прекрасно понимая, какие плюшки им сулит умение работать с этим ЯП.
скорее не хотят.
всего-то надо увеличить зарплату раза в 2 и софинансировать курсы кобола для кандидатов.
для вкатывания в тупиковую технологию - достаточная мотивация ?
Сейчас Руби программиста не могут найти за цену коня, а ты про Кобол говоришь, заведомо мертвый язык. Даже изучив Кобол после закрытия проекта работу ты себе не найдешь. Так что Кобол никому не нужен. Хотя по идее на нем написано 240 миллиардов строк кода.
> Даже изучив Кобол после закрытия проекта работу ты себе не найдешь.После закрытия проекта тебе долго не надо будет работать. Потому что на Коболе люди получают гораздо больше рынка. А за то время, как будешь искать работу, можно и другой какой язык освоить.
> Сейчас Руби программиста не могут найти за цену коня,много нетрадиционных рубистов было в Днепропетровске.
наверняка можно их найти и сманить, но искать придется в Польше.ps: что тормознее и ресурсожручее - Питон или Руби ?
Неправильная постановка вопроса. Правильная - что позволяет, и более того, поощряет использовать говнокод и подключать, не думая, кашу из сторонних либ? Подсказка - не Python.
Питон!
Так уж и быть раскрою тебе тайну, всех нормальных вменяемых рубистов переманили к себе несколько галер. Совсем всех. И теперь чтобы поддерживать свой руби проект надо обращаться на галеру и соответственно платить высокий прайс. Знаю как минимум один американский проект связанный с грузоперевозками, вот они они искали искали и и не нашли в штат рубиста ни за x2 ни за x3, плюнули работают с галерами. Планируют слезать с Руби.
Галера, поставляющая разработчиков из восточной Европы, дешевле, чем штатный американец. Да и напрямую найти не сложно - берешь название галеры, ищешь по ней в LinkedIn, и делаешь прямые офферы.В общем, прохладная история. Скорее всего, просто не умеют искать, да и галера устраивает
>Сейчас Руби программиста не могут найти за цену коняЯ для друга интересуюсь, можете пример накидать где ищут руби программистов, ну типо обучение или джун там, и чтобы за цену коня?
И какая у коня нынче цена?
Присоединяюсь. Готов даже раби выучить.
> Присоединяюсь. Готов даже раби выучить.Посмотрел бегло по европам.
В Германии хотят руби джуна с 2хлетним опытом.
Ну на этом можно вопрос закрывать.Хотят за 3300 примерно в месяц, что за вычетом налогов будет где-то 2300.
Не похоже что выше средней ЗП для других языков.
Джун всегда стоит как джун мозг включай.
> Джун всегда стоит как джун мозг включай.А мидл всегда как мидл, или не всегда?
А сеньер?
В любом случае, я ни одной вакансии конкретно на джуна не нашел пока.
Но и неплохо бы увидеть и вакансию на синьера с особой ценой оплаты труда.
Джун всегда будут по цене джуна. Денег стоит готовый специалист, в обучение которого не надо вкладываться.
> Джун всегда будут по цене джуна. Денег стоит готовый специалист, в обучение
> которого не надо вкладываться.Ну так если специалистов не хватает, тем более даже за деньги, логично джунов искать?
Покажите джуна по цене джуна.
Я пока вот нашел только мидла которого хотят купить как джуна.
И странное у вас рассуждение, платить "конскую" ЗП выгодно, а в обучение вкладывать невыгодно?
Почитай книжку «Капитал. Критика политической экономии» К. Маркс. Может быть хоть чуть чуть поумнеешь.
> Почитай книжку «Капитал. Критика политической экономии» К. Маркс. Может быть
> хоть чуть чуть поумнеешь.Спасибо за совет. Но вопрос был о конкретных вакансиях с повышенной оплатой труда.
Как-то так:
Всего-то сорок лет понадобилось.
>если у тебя вся инфраструктура на нёмА нечего было на него завязыватся!
А если других вариантов тогда и не было?
Были-были. Только фанаты питона не хотели их замечать. И более того, заменяли своими питоньими велосипедами решения на других языках.
Причём здесь вообще фанаты Питона? Как будто они выбирают те или иные решения. Подсказка: нет, это делают не они, этим занимаются менеджеры, исходя из примерно следующего набора характеристик: охват предметной области, доступность техподдержки, наличие на рынке готового персонала, наличие уже проделанных внедрений (никому не охота быть пионером) и т.п. вещей.
Очень много было в прошлом тимлидов, которые навязывали руководству питон как язык для разработки проекта. Просто в силу симпатий к языку.Возьмем год так 2010й
>охват предметной области,
>доступность техподдержки,
>наличие на рынке готового персонала,
>наличие уже проделанных внедрений (никому не охота быть пионером) и т.п. вещей.По сравнению с пхп, перлом везде у питона был провал. Однако, его пихали везде. С тех пор в принципе мало что изменилось.
Кстати, где сотни тысяч проектов на питоне? Пхпшных море, перл кое-где доживает в виде легаси, голанг за 10 лет уже везде, каждый первый проект имеет в своем составе какие-нибудь микросервисы на голанге. Где же прячется питон?
Перл нигде не используется с 90х, а где используется, можно многое сказать об авторах. Пхп это ад вроде битрикса, но не универсальный язык. Они оба языки процессинга страниц, и питон идеальный язык для приложух. Кстати, 2010 -- это тёмные времена. Ну и го никогда не выйдет за рамки околовебнявого тяп-ляп применения.
Как нибудь поинтересуйтесь спомощью чего строятся deb пакеты.
Это не интересно. Но я прекрасно осведомлён, где у меня в системе используется перл, только в этом нет ничего хорошего -- больше всего проблем при обновлении доставляет именно он. Если альтернативы exiftool что-то не видно (хоть и сомнительная прога), то всё остальное уже откровенное васянство и можно выкинуть безболезненно.
Django к примеру.
Tensorflow, Pytorch
Tensroflow написан на С++. В репо Pytorch половина кода на C/C++. Даже святая свитых numpy использует какой нить OpenBlas который на C, Fortran и Assembler. Где ваш питонобох теперь?
> DjangoОй, в код этого проекта лучше не смотреть. Это позор Python'а какой-то. Всю парадигму Java натянули на Python. Получилось мама - не горюй
Это шутка такая? Про питон из каждого утюга хвалебные оды льются.
> других вариантов тогда и не былоПока не начал завязываться на питон - вариантов ровно столько, сколько есть пригодных для этой задачи языков.
Смешной?
Тут рассматривается вариант что есть тулза на питоне и есть куча других языков на которых ты можеш повторить тулзу на питоне.Естественно большинство выбирает готовую тулзу.
Читай внимательно оба комента. Прохожий упомянул о некоем "тогда", когда "других вариантов не было". А то того было предшествующее "тогда", когда не было варианта и на питоне. И вот именно "тогда" и были варианты начать писать на любом другом языке. Они и позже никуда не делись, просто объём работы, сделанной на питоне на годы, придётся сделать на альтернативном языке за недели.
> Нет, если у тебя вся инфраструктура на нём.А вот здесь вы берёте за разные места системного архитектора, это допустившего, и пристально глядя в глаза, вопрошаете - КАГ ТАГ ТО, РОДНОЙ?
> С нуля Ансибл написать?Да, это будет сложновато, для такой ужасной архитектуры нужно иметь особый талант и подходящие условия. Боюсь, второй раз продать Ансибл сообществу уже не выйдет. Да и незачем в общем-то, есть уже написанные альтернативы, одна другой хуже, выбирай любую — страдания обеспечены.
мы поняли, что ты не осилил, завидуй молча
В целом да. Пихают его где надо и не надо.
Не проще, альтернатив то не существует. Фактически, большинство пользователей никогда не сталкиваются с ограничениями gil, на практике встрять в него надо уметь. В то же время, это весьма надёжный механизм, а те, кому он мешает, подключают сишные батарейки и пишут с его отключением в cython. Ну а насчёт того чтоб не учить, зачем отказывать себе в использовании самого надёжного, продуктивного и эффективного языка программирования, созданного за всю историю человечества?
>самого надёжного, продуктивного и эффективного языка программированияБыл бы он самым эффективным, не надо было бы писать модули на Си и заниматься модификациями, описанными в этой статье. Нет, этот язык далёк от эффективности, если мы говорим об универсальном языке. Но в некоторых областях он неплох.
Это интерпретируемый язык, максимально эффективно расширяющийся нативным кодом. То что написано в статье, это актуально в основном для больших систем, занимающихся вычислениями. Вот там где гц и гил начинают путаться под ногами и оттягивать на себя значительно ресурсов.
Ещё раз. Я не считаю язык программирования универсально эффективным, если он нуждается в присутствии других языков. Это касается всех языков, не только Питона, если что. Увы, люди пока не изобрели серебряную пулю, где одним языком программирования можно было бы заткнуть все потребности.
В каких-то нишах Питон можно считать эффективным. В других - нет, нельзя.
Он нуждается в присутствии других языков, он написан на другом языке. А в чём отличие пропатчишь ты интерпретатор или подгрузишь точно такой же модуль как и стандартные компоненты?
Отличие в том, что нужного модуля под рукой может не оказаться. Его придётся писать с нуля. И это будет уже другой язык программирования. Для этого нужно или будет его освоить, или найти отдельного человека под эту задачу. Это дополнительные деньги и время.
Есть такой язык. Zig называется
А что если он так эффективно расширяется из-за просты в том числе гил. А после нововведений перестанет легко расширятся. И мешаться будет на гил, а сам питон. Для совместимости нужен будет питон в котором часть работает с гил, часть без, фрагментация, усложнение, забвение.
Точно максимально? А то мужики-то и не знали.
Вы там в своем питономирке совсем оторвались от реальности.
У cython производительность си, куда уж проще и эффективнее. Так что да, лучше ничего не придумали.
Удивительно, в питоньем мире, чтобы получить хоть какую-нибудь адекватную производительность, надо использовать транспилятор в си
Ничего удивительного. Если у тебя цель по максимуму всё реализовать в pure-python, работать оно будет не слишком эффективно. Кстати, по этой же причине любители pure-python имплементаций первыми обнаруживают сущестование гила и потом плачутся о низкой производительности.
давай примеры, трепло
Вы там сишники ваще головой ударились в косяк? Зачем тебе вообще какието интерпретаторы. Пиши все на С. И баш тоже не используй, и мейк.Все же можно на С написать!! Давай вперед. Пиши.
> Нет, этот язык далёк от эффективностиОн никогда не декларировался как эффективный и не задумывался таким.
Это примерно как сказать "Нет, ассемблер всё-таки далёк от лидерства в скорости написания на нём приложений".
>весьма надёжный механизмНадежный, как костыль.
Вообще, встрять в GIL элементарно - достаточно начать бездумно создавать потоки и неизбежно нарвёшься на голодание. С другой стороны, можно прекрасно обойтись без них т.к. у Питона отличная поддержка много-процессности и асинхронщины.
Отличная? Даже отличной от других не назовешь, потому что завезли ее последними, копируя костыли из других языков. Вот у луа отличная асинхронщина (всегда была, с самого начала). В перловом Coro отличная, не уступающая луашной.
Если бы у питона была отличная поддержка асинхронщины и много-процессности GIL никогда бы не было.
смотрите, дети -- это спесалист классический, не трогайте его руками
Асинхронщина и многопроцерность к гилу никакого отношения не имеют.
Для справки. Не благодари.
А нафига он вообще нужен?
В чём сокральный смысл сией сущности?
Нам так то вообще без разницы, что и пайтон ты тоже не осилил
Так альтернативы то нет.
Perl умер, php ещё хуже, lua и не близко по функционалу.
Остальное все в другой весовой категории.
Про php смешно уже то, что вы его упомянули в этом списке. На питоне пишут (недо?)системные утилиты, php для этого ну совсем не предназначен.
Пхп точно не хуже питона для недосистемного. В нем все есть, в принципе. Многие утилиты пишут вспомогательные. На сервере приложений уже есть пхп, на чем скрипты писать? Не на питоне же.
пап точно хуже во всем абсолютно, более ужасной архитектуры просто не существует
>точно хуже во всем абсолютно
>просто не существуетСекта
Полностью плюсую, бОльшая часть софта берётся и постепенно переписывается на Go (или Rust где нужная прям мега-скорости или мега-безопасность). Всё получается в сто раз проще сопровождать (шиппить, тестить, рефакторить) и over 9000 раз ускорение.
Уже 6 лет занимаюсь переписыванием с такого г**на как JS/TS/Python/PHP на Go, всегда всё выходит огонь, исчезают тонны проблем.
Хватит душить змею! Всем синего хомяка!
Вот уйдешь ты куда-нибудь, не важно куда, кто будет то г**но, что ты написал, поддерживать и/или переписывать его в очередной раз?
В go уже завезли поддержку разделяемых библиотек (.so, .dll)? Или всё ещё собирают бинарники по 25МБ, потому что диска у всех много?
Надеюсь никогда не завезут. Слава Богу там один бинарик и пусть он будет хоть 250 мегабайт, кого это е**ёт?
НУжен terraform, nomad, или kubectl? Просто скачал бинарик и ВСЁ. А макаkи, пишущие поделия зависящие от разделяемых библиотек пусть продолжают выкладывать 350 версий своего продукта жизнедеятельности под разные ди срибутивы и их версии...
> Просто скачал бинарик и ВСЁЯ пользователей не-windows имел ввиду. Там описанные вами проблемы решаются пакетным менеджером.
> кого это е**ёт?
МЕНЯ. Можно, специально для меня, поддержку разделяемых библиотек? Вы же сможете продолжать пользоваться бинарниками по 250 мегабайт, как и любите. Или вы хотите, чтобы ВСЕ жили так, как нравится ВАМ?
Нет конечно. Живи как хочеш. Не нравятся бинари по 250 метров. Перепиши с го на С и нет проблем. Пользуйся маленьким бинарником с разделяемыми библиотеками.
Зачем выкладывать под разные дистрибутивы? Выкладываете исходники и инструкцию по сборке — сами соберут.
ну-ка, ну-ка, че ты там переписал, давай ссылки, псмеемя (inb4 никаких ссылок ты предоставишь, потому что ты типичное местное трепло)
Именно, Вася!
Работа у тебя есть благодаря тому что кто-то налабал говна на питоне , яваскрипте , ПХП.
И это говно нагенерило достаточно бабла чтоб нанять макаky Васю который просто перепишет готовое решение на другой язык.
>Хватит душить змею! Всем синего хомяка!Не, лучше живая змея (душили - душили, душили - душили), чем синий хомяк.
Собака лает - Пайтон развивается и его использование ни разу не сокращается.
Начни хотя бы со своего дистрибутива. Что, сынок, не выходит? То-то же.
Злая но правда.
> Избавиться от питона во много раз проще. Более того, не начинать его учить
> или использовать - ещё проще.Да даже можно и не избавляться. Все равно период полураспада софта на нем едва ли год.
> Да, 20 лет нямкали коричневую субстанцию с gil и ещё 5 или 10 - без разницы.
Тоже не понимаю чего они парятся. Что так питон "не тормозит", что этак. Один поток но побыстрей или много но чуть медленнее, можно подумать кто-то заметит.
Наконец все сишные дополнения для питона улетают в гарбедж, а без них питон превращается в унылый го.
ничто никуда не улетает.
Всё улетает далеко и на долго, думаешь всем захочется переписывать все сишные пакеты для питона? Спойлер никто не будет этим заниматься от слова ваще.
Что и зачем там переписывать? Внешние (сишние) библиотеки типа numpy и так отдают gil на время выполнения сишного кода. Gil касается исключительно питоновского кода и исключительно многопоточности (не многопроцессорности).
Т.е. надо будет свою батарейку и писать и тестировать на двух версиях питона с гил и без гил, просто потому что. При этом наверняка будут те кто работают только с гил, те кто только без гил. А кому то точно понадобится иметь обе батарейки вместе. Короче опять проблемы на ровном месте как с питоном 2.
Под эти две версии, предположу, попадает очень узкий круг задач. Поэтому вряд ли стоит раздувать из мухи слона. Проблемы есть, но они не космического масштаба, и уж точно не сопоставимы с Питоном 2.
Если условный код работал без использования gil то ему как-то наплевать что его теперь и вовсе нет. Если же некий код использовал gil для синхронизации, то (о, ужас) ему теперь придется мириться с тем что gil всегда получается быстро и гарантированно. Что делает его использование для новых версий питона попросту избыточным. Пусть пока лежит как deprecated для старых питонов.Отсылка ко второму питону и вовсе странная. Какую такую сишнюю библиотеку таки не портировали на третий питон? И почему питон не загнулся в то время, а наоборот, стал одним из лидеров? Отказ от gil без нарушения обратной совместимости - это самое лучшее что можно пожелать. killer feature.
Ты думаешь сейчас можно вспомнить ту кучу библиотек, которые по 5 лет никто не переписывал на 3-ий питон и приходилось их тащить в проде? Напомню прикол ты наверно не в курсе чтобы перейти на 3-ий питон нужно что бы все. Совсем все библиотеки, Карл! перешли на 3-ий питон, только тогда можно весь проект переводит на 3-ий питон.
исходное утверждение выше по треду было что никто под новую версию ничего переписывать не будет. Так вот, история с 2на3 показывает что будут. Тем более что особо и переписывать то нечего. Проблема убрать гил - она на стороне интепретатора питона, а не сторонней библиотеки.
Безопасной многопоточности не бывает, правильно тут сказали.
Haskell/STM?
Akka actors?
Их не так много. Все биндинги и обвязка на cython, всем нормальным проектам уже надоело что всё разваливается каждый минорный апдейт по причине очередной перестановки кроватей и они написали нормально. Учитывая, что основной их код всё же не на питоне, исправления будут тривиальны. Кстати, прямо сейчас у тебя есть возможность словить сегфолт 1001 способом у pycurl, например, и гил не поможет.
Ну вот решения на основе костылей, а потом костылей костылей. Мрак.
Вы читали как устроена сборка мусора в объектах Python?Можно же заблокировать два сравниваемых объекта, сравнить их и
отпустить работать дальше.Да, возможно появиться какая-то более расширенная функция блокировки
объектов для глубокого сравнения, но это уже на усмотрение авторов
библиотек.
Все кто ненавидят Питон, просто вы завидуете. Пока вы там выискиваете баги при сборке многоэтажных шаблонных конструкций непрерывно таскаемых из одного проекта в другой, мы пьём смузи, ходим в спортзалы и гуляем с девчонками. GIL за всё время проходил мимо меня. Там где нужна параллельность я просто создаю новый процесс и работаю через сокеты, делов то.
З.Ы.
Работать должен компьютер, а не человек.
Пока питонисты мечтают чтобы им кто-то позавидовал. И пытаются сами себе засунуть палки в колёса своего велосипеда. Го программисты просто наслаждаются жизнью.
Наслаждаются жизню с interface{}, iota, if err!= nill и.т.д.
Что не так? Опять зависть?
Я не являюсь ненавистником Питона, но, к сожалению, есть такая тенденция, когда этот язык применяют не по назначению в виду простоты его освоения. Например, в областях, где от софта требуется производительность, отзывчивость.Скорее всего, ты за все свои 15 лет не принимал участия в разработке таких продуктов. На Питоне их пытаться писать - та ещё боль. Когда некоторые понимают, что Питон не для этого, переписывают всё с нуля на другом, более подходящем языке.
Каждому языку - своя ниша.
Подтверждаю как тот, кто зарабатывает на жизнь питоном. Он не может быть правильным выбором везде, всегда и для всего.
Может. А теперь потрать остаток жизни, доказывая, что я неправ. Питон - это не только CPython, а ещё и Cython, IronPython, PyPy, RustPython. Может скоро GoPython появится. Напииши своего питона :)
С нуля ли? Переписать прототип, выявив узкие места на ранних стадиях, он всё же позволяет. Переписывать при необходимости это нормально. Ещё более нормально переписывать только части, производительности которых не достаточно. И насчёт простоты освоения я эээ не уверен, это один из самых сложных языков на моей памяти. Скорее, применяют в виду скорости и лёгкости внедрения, наличия большого числа качественных готовых компонентов.
Иногда с нуля. Так происходит, когда авторы на старте не понимали в итоге, на какие грабли наступят. Кажется, с Дропбоксом так было, ЕМНИП.
Но был ли бы вообще дропбокс, если с самого начала делали без питона? А ютуб? А если бы у конкурентов при этом питон был? Какой-нибудь инстаграм конечно ничто не мешает сделать на чём угодно.
История не терпит сослагательного наклонения. Думаю, был бы. На Питоне свет клином не сошёлся. Есть куча других языков.
Поэтому и дропбокса скорее всего не получилось, пока выучишь эти все языки состаришся и умрёшь, а питон быстро выучили написали дробокс и привлекли инвесторов). После, конечно, занялись оптимизацией.
> На Питоне свет клином не сошёлсяЯ думаю, это тот самый единственный случай, для которого эта фраза была напророчена.
> Но был ли бы вообще дропбокс, если с самого начала делали без питона? А ютуб?И торренты, прототип которых был реализован "в одно лицо" - не факт что были бы (теоретических проектов P2P в то время было вагон и маленькая тележка - по 40 штук на конфах представляли, а вот с реализацией не самых простых алгоритмов на "труЪ" ЯП - было не очень. Потому что на практике как-то оказывалось, что теоретики опять "забыли про овраги").
Ютуб начинался с PHP проекта.
> Ютуб начинался с PHP проекта.Насколько быстро осознали ошибку?
Как продались ютубу те сразу поняли ошибку) И для ускорения те перешли на питон. Да, да тут все орут про медленный питон, а питоном ускоряли проекты ещё в стародавние времена.
Какому ютубу, гуглу они продались, лол.
А зачем пытаться писать на Python такие приложения, изначально понимая, что язык для этого подходит крайне слабо? Ну, это автоматически профнепригодность...
> есть такая тенденция, когда этот язык применяют не по назначениюА где про это назначение можно прочитать, кроме твоих мыслей? Википедия называет его языком общего назначения, врут небось? На официальном сайте пишут, что Питон «very attractive for Rapid Application Development, as well as for use as a scripting or glue language to connect existing components together».
Канешна-канешна, для стажа 15 хлебания непотребовалось понимания, что внутри одного процесса содание, ресурсы, бестродействие потоков\фиберов, интеркоммуникации и мютексы\фютексы\семафоры гораздо дешевле и быстрее, чем все то же самое для процессов.
Так человек дал понять что он не торопится по жизни.
А куда торопиться, пока есть люди, готовые платить питонистам зарплаты?
Есть огромный класс задач, которые хорошо решаются на одном ядре и в один поток. Есть широкий класс числодробильных задач, которые не лезут в одну машинку. В обоих случаях на GIL вообще пофиг - мы работаем с процессами. А бывают приложения, где используются потоки: это либо десктоп с его отзывчивостью, либо криво состряпанные IO bound - вот им GIL иногда мешает. Питон на десктопе? Короче, выкинут и ладно - нормальные люди даже не заметят.
А кто ненавидит питон?
Мне лично почти фиолетово, есть он или нет.
Думаю, многим так же.
> Все кто ненавидят Питон, просто вы завидуете.А вот и нет. Нас задолбал левый пиар всякого мусора, спам в поиске, вечно не работающие скрипты всунутые такими как вы, так что через пару лет проект собрать невозможно, вечный breakage и сотни багов, как и общее качество кода в стиле "разреботчик не парился обработкой ошибок" и "привычно упало с трейсом на 2 экрана в ран тайм".
>как и общее качество кода в стиле "разреботчик не парился обработкой ошибок" и "привычно упало с трейсом на 2 экрана в ран тайм".Питон то тут не при чём.
Скорее уже сишка тут и сипипишка(привет КДЕ)
Правильные приложения падают с сегфолтом)
> привычно упало с трейсом на 2 экрана в ран таймэто в Java
Там где нужна параллельность я просто создаю новый процесс и работаю через сокеты, делов то. - гниль ппц. Страшно представить весь рак с синхронизацией, что у Вас там в обиходе.По моему опыту вопросы с производительностью у Питона до сих пор не имеют хороших решений и как только проект на python упирается в производительность, то переписывают на другом языке.
А смысл? Им платят за такие решения, рыночек требует таких решений, а свои правила можешь ну своей воображаемой подруге рассказать, когда питонист в этот момент будет гулять с 10ми настоящими
Я искренне ненавижу^W завидую Python, и это выражается в том, что в сраном Python:
1. Нет нормального маршалинга и стандартизации байткода. Вместо этого https://docs.python.org/3.11/library/marshal.html
2. Нет нормального JIT-компилятора, чтобы работала вся грамматика, но зато есть 1001 который частично работает почти со всеми языковыми конструкциями и который увеличивает производительность в паре краевых случаев, но в паре других все ухудшает
3. Нет нормальной сериализации в XML. Вместо этого есть это: https://docs.python.org/3/library/pickle.html
Барахло, которое 5 раз меняло спецификацию и которое полный NIH. Вместо того чтобы использовать стандарт W3.org вроде XML, они пишут гадость.
4. Python и кроссплатформенность - это шутка такая. Этот язык работает предсказуемо только на Linux, другие ОС поддерживаются так, что нужно писать тонну обвязок и изменять семантику действий.
5. Сообщество дурачков. Там правда сидят люди которые скажут, зачем тебе XML, если есть JSON.
Уровень образования настолько низок, что они не понимают:
- что такое SAX-парсер и почему DOM-а не хватает.
- не видели больших XML-выгрузок БД размером в пару сотен гигабайт, которые JSON-сериализатор не способен прожевать, потому что JSON должен всё это сначала загрузить в память, а XML работает и так через XPath и XSLT
- не видят жизни за пределами RESTful API, потому что других никогда не видели, а из-за убогости всех без исключения XML-библиотек в питоне, использование SOAP - это опять тонна рутины.Я к своему огромному сожалению поддерживал и дорабатывал 2 внутренних "бизнес-продукта" на питоне каждый по 10k и 20k строк кода. Считаю это время самым потерянным в моей жизни, потому что в основном писал обвязки, проверки ОС, проверки интерпретатора, разборы XML вручную, ручную сериализацию в текстовый документик, чтобы поддерживало API на другом конце. А бараны из "сообщества", рассказывают сказки, что "мне это не нужно", "есть Python way", "поменяй/перепиши продукты на другой стороне API". Фантазёры, думал я. А потом я последовал их настойчивому совету и мы просто сели с пацанами и переписали... Переписали на .NET 6. И кода меньше и работает быстрее и сопровождать не надо столько.
Единственное что я могу сказать точно, что конкретно GIL - это абсолютно незначительно по сравнению с проблемой в п.1 и п.2. Отсутствие стандартизации, и как следствие отсутствие JIT в сочетании с AOT компиляцией приводят к тому, что это барахло работает так медленно, что выпиливание GIL вообще ничего не решает.
> Работать должен компьютер, а не человек.
Вот точно! Но не понятно при чем тут Python. Мерзкая дрянь, которая тратит время на написание бойлерплейта до такой степени, что там в некоторых модулях 60% обвязок, и 40% функционала.
Моей зависти предела нет, ведь я всю жизнь мечтал использовать Python, чтобы писать и переписывать бойлерплейт, писать и поддерживать автогенерацию бойлерплейта, делать обвязки для кроссплатформенности бойлерплейта... фу.
Причем тут язык, если вся проблема, что вы выбрали ту работу, которая вам не заходит, вас под дулом пистолета туда привели и к батарее приковали?-)))
А за последние 25 лет, я много видел мусорного кода, что на Питон, что на Java EE, что на С. Проблема не в языках, а в прямых руках кодеров и мозгах архитекторов.
>> Сообщество дурачков.
> Причем тут язык, если вся проблема, что вы выбрали ту работу, которая вам не заходитВот именно про такую дурацкость в сообществе я и пишу.
Проблемы, которые я описал в п.1 - п.4 - это проблема именно языка, его интерпретатора и его стандартной библиотеки. Они не привязаны к моей работе лично или чьим либо проектам вообще. Наоборот, эти проблемы усложняют написание качественного и быстрого кода на питоне!
Сейчас это убогий по скорости, нестандартизированный, некроссплатформенный язык без поддержки сериализации не умеющий толком ничего кроме REST. Тут даже "jack of all trades" и универсальность языка не аргументы, потому что кто мешал написать стандарт байткода при переходе от 2 к 3? Кто мешал написать SAX-парсер для классов питона? Кто мешал прикрутить аннотирование к функциям и конструкторам?
Это тот самый случай культивирования культа карго. Питонисты не понимают, зачем это всё нужно, поэтому выкаблучиваются про то что "задача не та", "проект не тот", "работа не та" и прочее "не нужно". Они реально не понимают, потому что не видели задач. А задачу перед ними никто не ставит, потому что язык ни черта не умеет и спроектирован комитетом. Его "архитектура" нечто среднее между С++ и COBOL по мерзотности. При этом авторы не меняют ничего, потому что нет запроса на изменение. Это средневековье, мрак и культ карго.
Я, без шуток, проще найду общий язык на эту тему с разработчиками 1С. Они пусть и знают что они "погромисты" одной платформы, но им не нужно объяснять, что такое DTO и почему некоторые проливки лучше делать через SOAP. И про отчеты знают.
> Проблема не в языках, а в прямых руках кодеров и мозгах архитекторов.
Вот тебе одна из таких историй. Собственно та самая, когда проект от аутсорсера перевалили мне.
Наняла фирма как-то 8 лет назад (по глупости) группу как выяснилось позже питон-разрабов (2 пацана / ИП), которых попросила написать модуль отчетности для нескольких корпоративных АТС (телефонные продажи и саппорт). В форме внутрикорпоративного вебсайтика и задачей в стиле "вы сами лучше знаете как это писать, мы вам скажем что в выводимых таблицах".При этом она этим аутсорсерам исправно платила за работу. И программа работала первые 2 года. Но как и любая отчетность эта тоже не стояла на месте. Были заказаны и оплачивались доработки на изменения отчетов и доработки на добавление новых отчетов. Со временем росло напряжение, потому что внезапно они не захотели поддерживать свой собственный продукт ни за какие вменяемые деньги! А когда их попросили помочь добавить их базу в ETL, чтобы сделать общий кубик (OLAP), эти придурки сбежали в истерике, разругались и не захотели больше работать, благо свой код они отдали без конфликта. Вот такое барахло мы с пацанами и переписывали на .NET, благо смогли найти контакт с истеричными аутсорсерами через год после того как они слились (у них реально был нервный срыв тогда от объема задач по этой статистике).
Казалось бы, а почему так, да? А потому что Python + Django + PostgreSQL.
- Когда ты используешь язык, который не работает по-нормальному ни с какой сериализацией, то каждый дополнительный ендпоинт обмена данными - это рукописный ад.
- Когда ты используешь MVC-фреимворк, то бизнеслогика отчетов смешана с техническим кодом и сопровождать это, когда много изменений логики и добавляются источники - сущий ад. Причем Django - "нитакиекаквсе" , они даже свое MVC называют иначе, просто потому что придурки^W "python way".
https://docs.djangoproject.com/en/4.2/faq/general/#django-ap...
Но это все равно MVC со всеми его плюсами и минусами.
- PostgreSQL - пожалуй самая плохая из всех возможных баз данных, когда дело доходит до визуализации и предварительной трансформации отчетности, пусть даже OLTP. Она пухнет, она тупит от Time Series, ей кластеризация - это набор костылей. И вот когда из этого барахла нужно кубы строить, то она понятное дело сама пролить данные и трансформировать не умеет. И в те годы не было Apache Airflow или был, но был молод. В общем кончилось это все переписыванием на ASP.NET Core + Angular + MSSQL для функициональных компонентов из которой проливалось все в PowerBI где были отчеты и дашборды наряду с другими отчетами компании.Мораль: не используйте Python и его фреимворки для динамичных внутрикорпоративных проектов. Вы сами же и выгорите, пока будете это сопровождать. Python - это вещь в себе, он плохо интегрируется, требует много рутинного бойлерплейта, всё переименовывает и делает "по своему" просто чтобы отличаться, плохо работает вне Linux и еще и жутко медленный.
> Мораль: не используйте Python и его фреимворки для динамичных внутрикорпоративных проектов.Любопытное чтиво, но мораль несколько другая получается. Смотри:
1. контора наняла пацанов сделать простую штуку, они сделали, штука работала
2. контора усложнила штуку, пацаны не справилисьМораль: дело не в инструментах, а в требованиях к продукту. С простыми требованиями справились пацаны попроще, требования подросли, пришлось нанять пацанов посложнее.
избавятся от gil и наваяют килотонны кода синхронизации. Кому мешает эта блокировка? Там где нужен параллелизм и производительность питон даже без блокировки не актуален
https://peps.python.org/pep-0703/ - вот тут как раз написано кому мешает GIL. Это люди из AI которые гоняют питон на тысячах ядер чтобы обучать ИИ модели. Это Google и Facebook и писать no-GIL тоже будут они - инженеры Facebook и Google. Автор Numpy сказал что уже готов к правкам для поддержки no-GIL. Судя по всему это неизбежно произойдет и на данный момент запланировано к версии питона 3.13 или 3.14 и планируют закончить в течение 5 лет.
Смысл сего? Питон не про скорость исполнения, не про параллелизм, питон про скорость написания.
С чего кстати питонисты взяли, что скорость написания у питона больше, чем у других языков? Аргументированно, если можно.
Больше сниппетов в копилоте, лучшая обученность чатжпт, гугл барда и бинга. В нашей компании уже как полгодаумение работать с этими чатботами является обязательным требованием. Да. представьте себе, нужно уметь задавать правильнве запросы.
Какая прелесть, подумать и написать - нет, нахерачить как-нибудь чтоб работало, а там перепишут если надо будет, зачем вам программисты вообще? посадите реальных маkак, пусть в чатики релевантные слова пишут, получают релевантный код, и пихают его перебором, как только тесты покажут зеленые галочки - в прод
А знание трудов Кнута в Вашей компании не требуют?
Скорость написания на питоне выше потому что готовых библиотек больше и они имеют простое API. Попробуй на PHP или на golang сделать генерацию речи по тексту. А вот в питоне под это уже 100500 библиотек в том числе под русский язык есть Silero AI которая генерирует очень правдоподобную русскую речь - крутая штука, советую попробовать чтобы понять за что любят python https://colab.research.google.com/github/snakers4/silero-mod...
Если у вас задача только сходить в БД и сгенерировать JSON то тогда действительно питон ничем не лучше того же C# - а в данной задаче даже хуже.
https://www.osp.ru/os/2000/12/178361
Понимаю, сравнение старое, но это хоть что-то
Питон не про скорость написания, а про лёгкость (по сравнению с другими языками) понимания уже написанного ранее кода.
Ваше мнение важно для нас. оставайтесь на линии.
И скорость написания, и лёгкость понимания.
Я так и не понял, когда приходилось читать полурабочий код на Питоне, почему иногда переменные определяют после использования.
> дополнительные C API и Python API для обеспечения безопасной многопоточности в существующем кодеЭто невозможно, по-крайней мере на этих языках. И нет, я не Rust ставлю в пример, а скорее какой-нибудь функциональный язык.
Без смены парадигмы невозможно сделать "безопасную многопоточность", никто за эти десятилетия так и не смог на императивных языках. И да, я знаю что в Python "следы функциональщины", но это так же заметно как "следы орехов" в шоколадке без орехов.
А чего не понятно будут две версии либ, безопасТная с гил и небезопасная без гил.
Так они и небещопасную многопоточность не запилят. Так что если ты прочитал сикп - наскоро запиливай новый не обременённый фичами язычок с интерпретатором (и следами орехов), делай к нему дискорд-сервер и зови туда как можно больше анимечников и брони - станешь новым Гвидо и заработаешь себе на безбедную старость. И книжек у орейлли не забудь настругать вместе с курсами на скиллбохе.
Запилить новый сборщик, новый режим компилятора, чтобы отказаться от GIL. После этого отвалятся все сишные модули, и придётся для их поддержки запилить нативный интерфейс.Зачем так извращаться, если проще сразу перевести питон на платформу JVM. Ну разве что придётся транслятор написать ещё один, но это проще чем существующий питон перетряхивать.
>проще сразу перевести питон на платформу JVMБыло 2 таких проекта. Jython (сдох) и GraalPython (абсолютно офигенен, всем рекомендую, только недоделан до сих пор).
Исчо один иксперд по сишним модулям для питона. Этот требует запилить для них нативный интерфейс. Уважаемый, такой интерфейс встроен в питон с незапамятных времен и называется ctypes. Позволяет дергать сишнюю библиотеку из питона, безо всякого участия со стороны сишней библиотеки (ничего даже не компилируя). Открою секрет - множество сишних библиотек именно так и опитонизировано. Вот с приплюснутыми это не проканает, но это тема бинарной совместимости разных компиляторов плюсов.
Позволять-то он позволяет, но только вот большая (если не большая) часть модулей вкорячивается со стороны си.
Хорошая статья, которую должен прочртать каждый: https://kipp.ly/jits-impls/
Пожалуйста, указываете названия статей рядом со ссылкой. How JIT Compilers are Implemented and Fast: Pypy, LuaJIT, Graal and More
С одной стороны увеличение производительности всегда хорошо. Но с другой это усилит порочную практику писать критичные к производительности приложения на Python вместо ориентированных на производительность языков.
Есть такая профессия - Python от GIL избавлять.
Во-первых: непонятно в чём трудность написать что-то на Си с параллельным доступом к... структурам? Вроде все объекты в Питоне - это структуры в Си. Ведь целый Линукс на Си написан, и такой проблемы не слышал.Во-вторых: сколько нытья с этого GIL, при том, что он мешает только, если параллельно делать вычисления на чистом Python (CPU-bound задача), а большинство задач на чистом Python являются I/O-bound (например, запрос в БД). CPU-bound задачи выносят в отдельные расширения (Numpy), которые умеют отпускать GIL.
Можно разбить задачу на отдельные процессы (например, asyncio + потоки + процессы). Запуск процессов дороже тредов/микротредов, но на процессы GIL никак не влияет.
отсутсвие прямого наследование/полиморфизма мешает, в остальном можно и послать С++ подальше...
Там в pep-0703 реально хотят к козе боян пришить. Большие дяди платят за AI/ML. Гвидо вовремя свалил :)
> Гвидо вовремя свалил :)Куда? Он же вернулся несколько лет как.
Да? Ну круто всё равно! Ni!
> Ведь целый Линукс на Си написан, и такой проблемы не слышал.Вот и выросло поколение не слышавших про big kernel lock. Его выпилили к ядру 3.0 в 2011 году.
Ну вот и услышал :)
я не питонист поэтому спрашиваю
threads = list(range(8))
threads[0] = threading.Thread(target=self.collect_a)
threads[1] = threading.Thread(target=self.collect_b)
threads[2] = threading.Thread(target=self.collect_c)
threads[3] = threading.Thread(target=self.collect_d)
threads[4] = threading.Thread(target=self.collect_e)
threads[5] = threading.Thread(target=self.collect_f)
threads[6] = threading.Thread(target=self.collect_g)
threads[7] = threading.Thread(target=self.collect_h)
это что феик? они будут исполнятся последовательно?
тогда зачем трединг вообше? для будушего зарезервиловали?
> тогда зачем трединг вообше? для будушего зарезервиловали?Для асинхронности. Параллельность и асинхронность вещи ортогональные.
Если гил не отпускается то последовательно, если отпускается то параллельно.
Гвидо и ко догадались выпилить GIL из Питона.
Шёл 2023 год.
Давно догадывались, но не решались из-за поломки огромного количества питонячьего кода.
> В долгосрочной перспективе (через 5 лет) интерпретатор планируется перевести по умолчанию на сборку только в режиме без глобальной блокировки, одновременно прекратив поддержку сборки с GILТо есть получаем 2 версии опять... А говорили, что ошибку c python3 больше не повторят.
Да пусть хоть 1000 версий питона будет в системе. Опенсорс - это свобода. А тянуть протухшее и никому ненужное легаси - это прерогатива винды (ActiveX, COM, DCOM, WMIC, DDE и другие никому непонятные слова).
Из за таких как ты, простой смертный перебирает 1000 версий питона чтобы запустить какой то софт который понадобился один раз в полтора года... А всё из за того, что кому то лень в .exe бинарник. Выеживаются как будто существует более чем полторы архитектуры и нужна кроссплатформенность.
А тебя не смущает 100500 версий .NET, DirectX и других библиотек в системе и ещё отдельно в папке с каждой программой, потому что разрабы не хотят системные использовать? Нет, потому что это просто файлы, которые лежат и никого не трогают. Также, как и питон.
Так можно хотя бы pyc линковать, но у них лапки.
Это, безусловно, хорошее дело. Однако, по моему мнению, когда нужны параллельные вычисления, Python — последнее, что должно прийти на ум адекватному разработчику. Корректная реализация параллельных вычислений и так достаточно сложна, чтобы её ещё больше усложнять динамической типизацией. А ещё я боюсь, как бы типичные погромисты не начали на радостях всё писать на Python: мол, а чё, все же ядра загружены, нафиг париться с оптимизацией говнокода.
