А можно ссылки на п.2,3,4? В доках по ссылке вижу только п.1., никаких специальных действий для vm_swappines = 1 там также не упомянуто. Гугл, к сожалению, тоже не помощник.
Вообще, я уверен, что этот параметр раньше был документирован по-другому. Никогда не слышал про всякие там filesystem paging и тп раньше, а этот параметр использую уже 10 лет как. Например тут (тоже кернел.орг, отметим) просто совсем другой текст. Вот какой-то такой текст я и помню.
Видимо, надо лезть в исходники и разбираться, если это очень надо.
Знакомая история. Да плюньте на ЖЭУ, сделайте сами. Вызвать сантехника, сказать унитаз течет. Договориться, чтобы отключил стояк (желательно весной, когда жарко), ну и либо с ним, либо с другим знакомым сантехником договориться, чтобы реализовал план. С пластиковыми трубами это час работы на радиатор. Разве что если у вас чугуны, то может их будет проще поменять заодно, чем городить огород из 20 переходников и резьбу нарезать ))
[vm.swappiness] represents the percentage of the free memory before activating swap
(представляет собой процент свободной памяти перед активацией свопа).
Теперь подумаем, какой смысл имеет значение 0 или 1. Да никакого! 1% свободной памяти от 8ГБ — это 80МБ. Т.е. например ни одна вкладка браузера не откроется.
С другой стороны если у вас ССД, и достаточно памяти (у меня например 32 ГБ), то дефолтное значение 60% (свободной!) памяти для активации свопа — это тоже нонсенс. Это 18ГБ неиспользованной свободной памяти. Зря гонять трафик через ССД значит сокращать время его жизни.
Поэтому я успешно ставлю vm.swappiness=20 и спокойно живу без всяких ООМ.
А по заглавной теме статьи — есть 2 вопроса, на которые есть 2 простых ответа.
Зачем линукс использует swap-файл? Ответ: чтобы а) увеличить размер доступной программам памяти б) чтобы сохранять процессы при переходе в спящий режим;
Почему линукс использует swap-файл? Ответ: потому, что ядро линукса поддерживает.
Крайне рекомендую поставить краны (или регуляторы) на батареи. Вне зависимости от шума, атмосфера в квартире станет комфортнее, если вы её сможете контролировать. Плюс, при открытых окнах и включенных батареях влажность в помещении крайне низкая, больше риск ОРВИ и всякие статические электроразряды. Ну и меньше будете улицы отапливать ))
Дисклеймер: к решению вопроса шума вышеуказанное не относится, просто совет.
Интересная штука, но мне кажется, дальше чем даты или какие-то простые скалярные конвертеры, использовать не стоит.
Пример с юзером — хорош для демонстрации, но на практике скорее всего приведёт к куче лишних запросов к БД. И главное, как мне кажется, это размывание логики — вставка модельной логики в декларативные УРЛы и вынос важной части обработки собственно запроса в другое место. Как только в этой части, считающейся декларативной, возникает сайд эффект — возникают проблемы.
То же, что и с сигналами — вещь в теории полезная, на практике приводящая к большому батхёрту, если не сдерживаться и не пичкать модели комментариями "смотри сигналы".
Если вы говорите о синтаксисе, то в питоне он и так довольно сильно ограничен. И расширяется крайне редко, в отличие от ЖС, в котором каждый год пол-языка добавляется. Вот гляньте в https://habr.com/ru/post/533672/ если интересно. И там мои комментарии, зачем всё это туда тащить, получили минусов больше, чем за все предыдущие 10 лет на хабре =) Каждому своё.
Дополнительные фичи, если нужны, должны вноситься в виде внешних библиотек.
В идеале — да. Но когда это невозможно, приходится синтаксис расширять. В случае с async например — @coroutine и yield / yield from очень сильно запутывали, и безусловно async/await на порядок проще. Или f-string, тоже значительно упростило многие вещи.
вроде как эта фишка должна помогать бороться с ошибками в сложных программах. Но, в моем личном опыте,
Ну опыт у всех разный. Лично мне (и со мной согласны остальные 15 человек в моей компании) оно сильно помогает работать с PyCharm, подсказки, переход к определению, подстановка атрибутов, в общем куча плюшек. Может, это даже важнее гипотетических ошибок, которые у опытных программистов и так нечасто бывают. Да и не нравится — не используй, в чём проблема, никто ж не форсирует.
А все писать только на питоне — это невозможно да и не нужно.
не всё. Но если у вас проект в 100000 строк, то чем богаче язык, тем проще писать.
Почему вы так против? В конце концов, вас кто-то заставляет учить все фичи? Вы можете использовать столько, сколько хотите. Можете даже форкнуть и удалить лишнее =)
Я пробовал писать на рельсах и джанго. Сравнения не в пользу последнего.
джанго — это всё-таки не питон, и вряд ли похвастается первым местом среди веб-фреймворков даже на питоне, не говоря уж о вообще. Плюс разрабы джанго — ребята крайне консервативные и некоторые баги и фичереквесты не закрывают по 10 лет. Насчёт устарел, отнюдь. Он вполне неплохо со своими обязанностями справляется. А сравнивать джанго с фласком, это как сравнивать грузовик с самолётом.
Да и rust ни куда не денется, и питон так и останется подражателем.
Это ещё кто кому подражатель, интересно. 5-летний Раст или 30-летний питон?
Непродуманные изменения, не поддержанные сообществом
это намёк на оператор моржа :=? :=) не в восторге от него, но пока что не особо и встречаю. Возможно, пройдёт пара лет, все попривыкнут.
Есть nim… Компилируемый, строго типизированный
так может в этом то и проблема?
Нужен компилируемый язык? — Жава, С, С#, тра-та-та… пара сотен таких есть, навскидку. Нужен интерпретируемый? Ну не РНР же, или ЖС с 900-страничным мануалом по синтаксису и встроенным объектам (без библиотек), где одним лишь описанием того, как работает конверсия типов, 10 страниц заняты, и где фичи можно (то есть нужно) включать флагом в файле настроек или вообще использовать внешний транслятор? Или перл, при всех его достоинствах пригодный разве что статью на хабре распарсить. Да, ещё руби, но по близости к человеческому языку и по читаемости питон всё равно намного впереди.
Нужен язык со строгой типизацией времени выполнения? GOTO предыдущий пункт. Не нужна такая типизация? Опять же, см. выше.
Так что пока не вижу причин беспокоиться за судьбу питона.
Очень просто объясню.
Низкий порог входжения никуда не денется от того, что в ЯП есть разные фичи. Но как только тебе надо шагнуть за порог, если за ним пустота, тебе придётся менять ЯП на другой, с более высоким порогом. Питон же как раз тем и хорош, что его не надо менять как перчатки.
Всегда будут 2 мнения. Одним солёное, другим сладкое. Код на питоне — лучший код из всех возможных императивных языков, имхо. И всё вами перечисленное без сомнения гениально. Даже если кому-то это ошибка, то по крайней мере https://www.northeastern.edu/graduate/blog/most-popular-programming-languages/ вот это говорит о том, что солидной части разработчиков она может приносить 120К баксов в год ))) а на вашем ЯП без None и исключений сколько?
в теории для питона ничто не мешает принять какой-нибудь новый PEP, в котором было бы описано поведение статической проверки исключений.
Если представить, что тайпхинтингу в питоне столько же лет, сколько самому Расту (который ещё сколько-то лет до релиза пилился), то в общем уже и тот результат, что имеем, неплохой. И я уверен, он будет развиваться.
Питон и вообще интерпретируемые языки пожалуй никогда не сравнятся с компилируемыми по возможности тайпчекинга. И таки да, там, где тебе помог бы компилятор, ты вынужден помогать себе сам. Но где делать эту проверку, ты тоже решаешь сам, и в этом плюс. :)
Обратная совместимость — это зло, что можно наблюдать на примере жаваскрипта )) Но согласен, можно было получше организовать. 3.0, 3.1, 3.2 — неюзабельные версии. Что ж, на ошибках учатся. С другой стороны проблему unicode vs str без поломки совместимости было не решить, а надо было решать. Или поддержка "старых" классов...
— Внедрение подсказок статической типизации.
Крутая вещь. В больших проектах очень помогает. Главное, никто не форсирует, не нужно — не используй, нет проблем.
— И вообще затаскивание в ядро языка вещей типа асинхронщины.
Асинк — это киллер фича и то, что вернуло довольно большой маркет бэкендного веба, который заметно стал утекать на ноду. Причём асинк в питоне реализован на мой взгляд почти идеально с точки зрения пользователя. Конечно, сама концепция сложна и требует тщательного планирования и понимания нюансов, но АПИ прекрасен. И опять же, никто не форсирует.
А вцелом по развитию питона, так оно как раз, кажется, сильно замедлилось после асинка.
Последнее значительное нововведение — f-строки в 3.6.
В последнее время, с 3.7, особо ничего нового и не появилось, так по мелочи.
А насчёт ухудшений… было бы интересно услышать ваше мнение.
Такой код будет корректным и не вызовет исключений, однако многочисленные проверки очень сильно увеличивают кодовую базу и сводят на нет всю простоту и лаконичность, которой славится Python.
Философия питона вообще-то Better ask forgiveness, than permission. Согласно этому, следовало бы использовать
К тому же, это исключение не обязательно ловить в месте, где оно возникает. Этот "минус" с точки зрения типобезопасности существенно экономит время разработки, потому что не нужно перечислять все возможные исключения только ради их перечисления. Но в теории для питона ничто не мешает принять какой-нибудь новый PEP, в котором было бы описано поведение статической проверки исключений.
В целом, как у любого инструмента, у статической типизации есть свои плюсы и минусы. Для компилируемого языка статическая типизация — это мастхэв, для интерпретируемого — это просто удавка на шее.
И совершенно не обязательно заниматься этим:
давайте перепишем Python-код по аналогии с Rust, не вызывая исключения.
Лучше писать на питоне как на питоне, а не по аналогии с Rust. Ну и наоборот :)
пока опциональная статическая типизация в Python выглядит недостаточно мощным инструментом, позволяющим избавиться от всех ошибок, связанных с несоответствием типов
и вероятно никогда и не станет. Начнём с того, что это не "статическая типизация", а статическая проверка типов. Если в язык занесут типизацию времени исполнения, то возможно это будет шагом к "избавлению от всех ошибок", а возможно — началом конца питона. А пока что вам ничто не мешает обойти эти проверки в случае необходимости.
Во-вторых, mypy это всего лишь один из инструментов проверки, который не реализует на 100% весь спектр возможных проверок (он не является референсом и постоянно дополняется). Есть и другие тулзы.
не холивара ради. Я отдаю себе отчёт, что вкусы у всех разные. И опыт тоже имеет значение. Отдав 18 лет вебу (профессиональной работы, не включая институт и поделки; из них 10 на питоне, до этого РНР и CGI/Perl, ну и куда же веб без ЖС), сейчас нет смысла вписываться например в Жаву или функциональщину. Как и вам в питон, по всей видимости. Поэтому я своё будущее связываю с питоном. И после перехода на питон, ни разу не пожалел =)
Про Руби я знаю, но не вижу в нём какого-либо сакрального смысла.
Опять же не ради холивара, на мой взгляд никаких особых преимуществ у статически типизированных скриптовых языков нет. Я всецело за подход питона: нужны типы — есть хинтинг. Как-то смотрю на этот хайп с TypeScript немного со стороны. Пока не зашло, слишком много проектов на ЖС.
… python: есть только 1 способ сделать что-то, и не важно нравится ли он вам
Не согласен. Право, не знаю, почему про питон ходят такие мифы, из-за There should be one-- and preferably only one --obvious way to do it. что ли? Так и тут не говорится про "только одну"… В питоне есть достаточное количество способов что-то сделать. А там, где больше одного не нужно, так зачем ещё?
Стиль кода более-менее стандартен, и тут вопрос "нравится-не нравится" обычно не возникает, потому что всё логично, бывают опять же исключения и крайние случаи, ну на то и есть всякие штуки, аналогичные eslint-disable-next-line.
Люблю языки с вкусным сахаром
Кто их не любит. И в питоне он есть.
А я ещё люблю языки с логичным АПИ, которое не надо каждый раз в документации проверять (впрочем, сейчас не так актуально, когда ИДЕ всё показывает), ну и конечно, функциональностью out of the box. Запуская голый питон, я могу сделать что угодно, от парсинга хтмла до НТТР-сервера, от десятичной математики до графики, причём мне не нужно изворачиваться в конфиге языка (!!! — кто вообще придумал, что синтаксис определяется внешними настройками?), чтобы включить удобоваримые модули, потому что они уже из коробки рациональные. Ну и… долго можно перечислять.
Я не говорю, что питон идеальный, есть косяки и в его АПИ, и есть вещи, которые в ЖС как инфраструктуре мне больше импонируют. Но в целом, питон как язык просто не сравним.
Поэтому мне как раз жаль времени, которое я трачу на решение тривиальных проблем в ЖС, которых нет в питоне, потому что увы, кроме питона мне приходится работать ещё и с ЖС ради зарплаты. =))
Хотя, скажу честно, есть и другой повод для меня работать с ЖС)) чтобы почувствовать прекрасное, нужно сравнить его с чем-то… не таким прекрасным. Если бы я не работал с ЖС, наверно я бы не любил питон так. Если бы я не работал с питоном, наверно был бы готов мириться, как и вы, потому что РНР (10 лет назад) было ещё хуже. Всё познаётся в сравнении.
А можно ссылки на п.2,3,4? В доках по ссылке вижу только п.1., никаких специальных действий для
vm_swappines = 1там также не упомянуто. Гугл, к сожалению, тоже не помощник.Вообще, я уверен, что этот параметр раньше был документирован по-другому. Никогда не слышал про всякие там filesystem paging и тп раньше, а этот параметр использую уже 10 лет как. Например тут (тоже кернел.орг, отметим) просто совсем другой текст. Вот какой-то такой текст я и помню.
Видимо, надо лезть в исходники и разбираться, если это очень надо.
Я не про тест, а про то, что
согласно документации не имеет никакого отношения к
В таком случае, смею заметить, в статье тоже "глупости":
:)
Хахаха, в самом деле. Не догадался в доки ядра посмотреть. А ведь эта ссылка — в топе гугла…
Знакомая история. Да плюньте на ЖЭУ, сделайте сами. Вызвать сантехника, сказать унитаз течет. Договориться, чтобы отключил стояк (желательно весной, когда жарко), ну и либо с ним, либо с другим знакомым сантехником договориться, чтобы реализовал план. С пластиковыми трубами это час работы на радиатор. Разве что если у вас чугуны, то может их будет проще поменять заодно, чем городить огород из 20 переходников и резьбу нарезать ))
Вопрос "Почему Линукс использует своп-файл" не раскрыт в статье. Вся статья собственно про
vm.swappiness = (0 | 1)Давайте просто посмотрим описание
vm.swappinessнапример тут: https://linuxhint.com/understanding_vm_swappiness/ :(представляет собой процент свободной памяти перед активацией свопа).
Теперь подумаем, какой смысл имеет значение 0 или 1. Да никакого! 1% свободной памяти от 8ГБ — это 80МБ. Т.е. например ни одна вкладка браузера не откроется.
С другой стороны если у вас ССД, и достаточно памяти (у меня например 32 ГБ), то дефолтное значение 60% (свободной!) памяти для активации свопа — это тоже нонсенс. Это 18ГБ неиспользованной свободной памяти. Зря гонять трафик через ССД значит сокращать время его жизни.
Поэтому я успешно ставлю vm.swappiness=20 и спокойно живу без всяких ООМ.
А по заглавной теме статьи — есть 2 вопроса, на которые есть 2 простых ответа.
И никаких мини программ не надо ))
да это везде так, почему нельзя поставить байпас? ставили без проблем в 2 квартирах. Как-то так:
Нельзя ставить кран так, чтобы он мог перекрыть стояк, это да. Но на отвод можно.
Крайне рекомендую поставить краны (или регуляторы) на батареи. Вне зависимости от шума, атмосфера в квартире станет комфортнее, если вы её сможете контролировать. Плюс, при открытых окнах и включенных батареях влажность в помещении крайне низкая, больше риск ОРВИ и всякие статические электроразряды. Ну и меньше будете улицы отапливать ))
Дисклеймер: к решению вопроса шума вышеуказанное не относится, просто совет.
Именно так. :)
удачное сравнение.
В общем спасибо за подкинутую идею, Today I learned как говорится.
Интересная штука, но мне кажется, дальше чем даты или какие-то простые скалярные конвертеры, использовать не стоит.
Пример с юзером — хорош для демонстрации, но на практике скорее всего приведёт к куче лишних запросов к БД. И главное, как мне кажется, это размывание логики — вставка модельной логики в декларативные УРЛы и вынос важной части обработки собственно запроса в другое место. Как только в этой части, считающейся декларативной, возникает сайд эффект — возникают проблемы.
То же, что и с сигналами — вещь в теории полезная, на практике приводящая к большому батхёрту, если не сдерживаться и не пичкать модели комментариями "смотри сигналы".
Если вы говорите о синтаксисе, то в питоне он и так довольно сильно ограничен. И расширяется крайне редко, в отличие от ЖС, в котором каждый год пол-языка добавляется. Вот гляньте в https://habr.com/ru/post/533672/ если интересно. И там мои комментарии, зачем всё это туда тащить, получили минусов больше, чем за все предыдущие 10 лет на хабре =) Каждому своё.
В идеале — да. Но когда это невозможно, приходится синтаксис расширять. В случае с async например — @coroutine и yield / yield from очень сильно запутывали, и безусловно async/await на порядок проще. Или f-string, тоже значительно упростило многие вещи.
Ну опыт у всех разный. Лично мне (и со мной согласны остальные 15 человек в моей компании) оно сильно помогает работать с PyCharm, подсказки, переход к определению, подстановка атрибутов, в общем куча плюшек. Может, это даже важнее гипотетических ошибок, которые у опытных программистов и так нечасто бывают. Да и не нравится — не используй, в чём проблема, никто ж не форсирует.
не всё. Но если у вас проект в 100000 строк, то чем богаче язык, тем проще писать.
Почему вы так против? В конце концов, вас кто-то заставляет учить все фичи? Вы можете использовать столько, сколько хотите. Можете даже форкнуть и удалить лишнее =)
джанго — это всё-таки не питон, и вряд ли похвастается первым местом среди веб-фреймворков даже на питоне, не говоря уж о вообще. Плюс разрабы джанго — ребята крайне консервативные и некоторые баги и фичереквесты не закрывают по 10 лет. Насчёт устарел, отнюдь. Он вполне неплохо со своими обязанностями справляется. А сравнивать джанго с фласком, это как сравнивать грузовик с самолётом.
Это ещё кто кому подражатель, интересно. 5-летний Раст или 30-летний питон?
это намёк на оператор моржа
:=? :=) не в восторге от него, но пока что не особо и встречаю. Возможно, пройдёт пара лет, все попривыкнут.так может в этом то и проблема?
Нужен компилируемый язык? — Жава, С, С#, тра-та-та… пара сотен таких есть, навскидку. Нужен интерпретируемый? Ну не РНР же, или ЖС с 900-страничным мануалом по синтаксису и встроенным объектам (без библиотек), где одним лишь описанием того, как работает конверсия типов, 10 страниц заняты, и где фичи можно (то есть нужно) включать флагом в файле настроек или вообще использовать внешний транслятор? Или перл, при всех его достоинствах пригодный разве что статью на хабре распарсить. Да, ещё руби, но по близости к человеческому языку и по читаемости питон всё равно намного впереди.
Нужен язык со строгой типизацией времени выполнения? GOTO предыдущий пункт. Не нужна такая типизация? Опять же, см. выше.
Так что пока не вижу причин беспокоиться за судьбу питона.
Очень просто объясню.
Низкий порог входжения никуда не денется от того, что в ЯП есть разные фичи. Но как только тебе надо шагнуть за порог, если за ним пустота, тебе придётся менять ЯП на другой, с более высоким порогом. Питон же как раз тем и хорош, что его не надо менять как перчатки.
Всегда будут 2 мнения. Одним солёное, другим сладкое. Код на питоне — лучший код из всех возможных императивных языков, имхо. И всё вами перечисленное без сомнения гениально. Даже если кому-то это ошибка, то по крайней мере https://www.northeastern.edu/graduate/blog/most-popular-programming-languages/ вот это говорит о том, что солидной части разработчиков она может приносить 120К баксов в год ))) а на вашем ЯП без None и исключений сколько?
Да, согласен. С другой стороны, я написал,
Если представить, что тайпхинтингу в питоне столько же лет, сколько самому Расту (который ещё сколько-то лет до релиза пилился), то в общем уже и тот результат, что имеем, неплохой. И я уверен, он будет развиваться.
Питон и вообще интерпретируемые языки пожалуй никогда не сравнятся с компилируемыми по возможности тайпчекинга. И таки да, там, где тебе помог бы компилятор, ты вынужден помогать себе сам. Но где делать эту проверку, ты тоже решаешь сам, и в этом плюс. :)
Хмм. Готов поспорить )))
Обратная совместимость — это зло, что можно наблюдать на примере жаваскрипта )) Но согласен, можно было получше организовать. 3.0, 3.1, 3.2 — неюзабельные версии. Что ж, на ошибках учатся. С другой стороны проблему unicode vs str без поломки совместимости было не решить, а надо было решать. Или поддержка "старых" классов...
Крутая вещь. В больших проектах очень помогает. Главное, никто не форсирует, не нужно — не используй, нет проблем.
Асинк — это киллер фича и то, что вернуло довольно большой маркет бэкендного веба, который заметно стал утекать на ноду. Причём асинк в питоне реализован на мой взгляд почти идеально с точки зрения пользователя. Конечно, сама концепция сложна и требует тщательного планирования и понимания нюансов, но АПИ прекрасен. И опять же, никто не форсирует.
А вцелом по развитию питона, так оно как раз, кажется, сильно замедлилось после асинка.
Последнее значительное нововведение — f-строки в 3.6.
В последнее время, с 3.7, особо ничего нового и не появилось, так по мелочи.
А насчёт ухудшений… было бы интересно услышать ваше мнение.
Философия питона вообще-то Better ask forgiveness, than permission. Согласно этому, следовало бы использовать
К тому же, это исключение не обязательно ловить в месте, где оно возникает. Этот "минус" с точки зрения типобезопасности существенно экономит время разработки, потому что не нужно перечислять все возможные исключения только ради их перечисления. Но в теории для питона ничто не мешает принять какой-нибудь новый PEP, в котором было бы описано поведение статической проверки исключений.
В целом, как у любого инструмента, у статической типизации есть свои плюсы и минусы. Для компилируемого языка статическая типизация — это мастхэв, для интерпретируемого — это просто удавка на шее.
И совершенно не обязательно заниматься этим:
Лучше писать на питоне как на питоне, а не по аналогии с Rust. Ну и наоборот :)
и вероятно никогда и не станет. Начнём с того, что это не "статическая типизация", а статическая проверка типов. Если в язык занесут типизацию времени исполнения, то возможно это будет шагом к "избавлению от всех ошибок", а возможно — началом конца питона. А пока что вам ничто не мешает обойти эти проверки в случае необходимости.
Во-вторых, mypy это всего лишь один из инструментов проверки, который не реализует на 100% весь спектр возможных проверок (он не является референсом и постоянно дополняется). Есть и другие тулзы.
не холивара ради. Я отдаю себе отчёт, что вкусы у всех разные. И опыт тоже имеет значение. Отдав 18 лет вебу (профессиональной работы, не включая институт и поделки; из них 10 на питоне, до этого РНР и CGI/Perl, ну и куда же веб без ЖС), сейчас нет смысла вписываться например в Жаву или функциональщину. Как и вам в питон, по всей видимости. Поэтому я своё будущее связываю с питоном. И после перехода на питон, ни разу не пожалел =)
Про Руби я знаю, но не вижу в нём какого-либо сакрального смысла.
Опять же не ради холивара, на мой взгляд никаких особых преимуществ у статически типизированных скриптовых языков нет. Я всецело за подход питона: нужны типы — есть хинтинг. Как-то смотрю на этот хайп с TypeScript немного со стороны. Пока не зашло, слишком много проектов на ЖС.
Не согласен. Право, не знаю, почему про питон ходят такие мифы, из-за There should be one-- and preferably only one --obvious way to do it. что ли? Так и тут не говорится про "только одну"… В питоне есть достаточное количество способов что-то сделать. А там, где больше одного не нужно, так зачем ещё?
Стиль кода более-менее стандартен, и тут вопрос "нравится-не нравится" обычно не возникает, потому что всё логично, бывают опять же исключения и крайние случаи, ну на то и есть всякие штуки, аналогичные eslint-disable-next-line.
Кто их не любит. И в питоне он есть.
А я ещё люблю языки с логичным АПИ, которое не надо каждый раз в документации проверять (впрочем, сейчас не так актуально, когда ИДЕ всё показывает), ну и конечно, функциональностью out of the box. Запуская голый питон, я могу сделать что угодно, от парсинга хтмла до НТТР-сервера, от десятичной математики до графики, причём мне не нужно изворачиваться в конфиге языка (!!! — кто вообще придумал, что синтаксис определяется внешними настройками?), чтобы включить удобоваримые модули, потому что они уже из коробки рациональные. Ну и… долго можно перечислять.
Я не говорю, что питон идеальный, есть косяки и в его АПИ, и есть вещи, которые в ЖС как инфраструктуре мне больше импонируют. Но в целом, питон как язык просто не сравним.
Поэтому мне как раз жаль времени, которое я трачу на решение тривиальных проблем в ЖС, которых нет в питоне, потому что увы, кроме питона мне приходится работать ещё и с ЖС ради зарплаты. =))
Хотя, скажу честно, есть и другой повод для меня работать с ЖС)) чтобы почувствовать прекрасное, нужно сравнить его с чем-то… не таким прекрасным. Если бы я не работал с ЖС, наверно я бы не любил питон так. Если бы я не работал с питоном, наверно был бы готов мириться, как и вы, потому что РНР (10 лет назад) было ещё хуже. Всё познаётся в сравнении.