Зачем Python?

Прикольно, это вывод типа сработал? Но у автоматического вывода типа обычно бывает множество ограничений. Тут явна математическая операция на числами из которой легко выводится тип. Посмотрел type hints, с ним можно писать и если ide поддерживает то просто отлично.

Ага, расскажи мне какой питон быстрый.

Многие используют

Не от хорошей жизни. Либо не от большого ума.

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

Код на статически типизированных языках в продакшене точно так же регулярно валится, с похожими отмазками

Если писать без оглядки на легаси-совместимость, то значительно экономятся ресурсы. Ну и потом async/await прикольные как минимум. Смазываем генераторы в корутинах евент лупами, инстант профит.

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

Тут скорее более общее, что у объекта нет такого метода. Конечно, это не всегда сработает. С type annotations намного лучше, тем более, их можно нагенерить автоматически https://github.com/Instagram/MonkeyType

а потом сбоку прилепить статику, которая не воспринимается интерпретатором

А нафига тебе приспичило статическую проверку кода пихать в интерпретатор? Кому-то легче станет, если её туда запихать и у конечного юзера программа не запустится с ошибкой? Она нужна только один раз после написания кода. Раз компилятора нет, значит нужна отдельная программа.

всё что хочешь тайпхинтами не опишешь

Чего ты такого странного хочешь?

Я думаю что программах написанных на статически типизированных языках практически никогда не возникает ошибок неправильного приведения типов в рантайме. По моим догадкам в python такие должны встречаться время от времени. Но это только моя догадка, я ничего сложного на python не писал. За годы программирования на Java я не помню ошибок приведения типов, зато практически всегда возникали NullPointerExcetpion и причину в обилии NPE многие объясняют тем, что в типах нет информации про то может ли ссылка указывать на null или нет. Следовательно нехватка такой информации в момент компиляции порождает ошибки приводящие к NPE в рантайме.

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

А чего ноешь тогда?

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

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

Используй жаву, если припёрло. Ставить свои проблемы в упрёк питону — завышенное чсв.

Следовательно нехватка такой информации в момент компиляции порождает ошибки приводящие к NPE в рантайме.

Да, это точно так же плохо, как отсутствие статической типизации. Вообще, для меня несколько странно, что разработчики статически типизированных ЯП проработали типизацию, что но с нулевыми значениями облажались. Из мэйнстрима: в C#, например, есть костыль NotNull, - но это такая же какаха, прилепленая сбоку, как и тайпхинтинг в питоне.

А чего ноешь тогда?

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

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

Попаболь у меня скорее не от того, что кто-то не заточил свой язычок, а от того, что такие язычки в топе сейчас. И нужно постараться найти проект, где бы хорошо платили и не использовали вот эту каку. А в вебе - там вообще швах, потому что JS во все поля... слава богу, немного ситуацию исправляет TypeScript... но сколько процентов проектов его использует? Единицы?

разве что ты пишешь на нем какую-то числодробилку

У нас есть структуродробилка с производительностью 1 запрос в секунду на процесс и ее скейлить приходится процессами, а не потоками, потому что GIL. И она обязана быть написана на Python, потому что часть ее работы буквально вычислять Python выражения

А нафига тебе приспичило статическую проверку кода пихать в интерпретатор? Кому-то легче станет, если её туда запихать и у конечного юзера программа не запустится с ошибкой? Она нужна только один раз после написания кода. Раз компилятора нет, значит нужна отдельная программа.

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

Можно пример что именно нельзя описать тайпхинтами?

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

Ха. Ха. Ха.

(Может в Ъшных языках вроде окамла и правда этого нет, но в сях это сплошь и рядом)

Можно пример что именно нельзя описать тайпхинтами?

List<Dictionary<string, MySomeType>>

У нас есть структуродробилка с производительностью 1 запрос в секунду и ее скейлить приходится процессами, а не потоками, потому что GIL

А почему «приходится»? У этого подхода есть какие-то недостатки?

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

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

Да, и занимаются этим часто, и void* по коду передают

Ха. Ха. Ха.
(Может в Ъшных языках вроде окамла и правда этого нет, но в сях это сплошь и рядом)

В сях++ (про них же речь?) есть наследие, позволяющее выстрелить себе в ногу, плюс позволяющее писать небезопасный, но быстрый код. Ежели приложение не упирается в производительность, нужно брать или другой ЯП, или писать на сях, строго придерживаясь типизации, а не жонглируя указателями на указатели.

Ежели ты про си без плюсов, - то он вообще ни разу не предназначен для разработки прикладного софта.

К вопросу почему нужно использовать Gtkmm с ее libsigc++ для сигналов вместо Gtk+

Ну память жрет

Там хотя бы тысяча процессов есть?

Вопросы люди задают чойта у вас столько процессов висит.

Про треды то же самое будут спрашивать, если узнают клавишу для их отображения в топе

https://imgur.com/a/HBV8QRy

Ладно, я облажался.

Там хотя бы тысяча процессов есть?

О да. Много терабайт памяти из-за того что сраный педон. Я бы даже не обсуждал если бы не было.

Я про то и другое

строго придерживаясь типизации

Это не так просто - создать в программе систему типов, которая реально помогает избегать ошибок. К тому же многие практические задачи требуют более динамического подхода. Упорка в типизацию часто приводит к появлению кучи шаблонного «бустокода», который трудно разрабатывать и поддерживать.

Это вам не факториалы на шаблонах считать.

Много терабайт памяти из-за того что сраный педон

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

Где-то прочел такую фразу

Python - это второй лучший язык для любой задачи.

В принципе, согласен, только иногда он может соревноваться за первое место.

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

Ты не знаешь что такое стабильность? Зато 5 звёзд на ЛОРе.

Ошибки действительно редкие, но как правило это None там где его не ждали, значит что-то где-то уже сломалось и это другая ошибка. Разве что не предусмотрели что что-то где-то у кого-то будет когда-нибудь отломано. У некрофильских дистров часто такие проблемы с совместимостью всего.

Твой код - это если твой личный проект.

Если тебе надо так форматирование сделай astyle, делов то. А быдлокодить можно и на пистоне нормально.

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

Тогда, в моих условиях, мне надо писать на pl/sql + delphi.

Люди привыкли кастовать без дженериков, игнорировать 80% предупреждений компилятора и лениться без повода. Так лучше бы на питоне и писали

И еще херили бы всё на свете благодаря ДП. Зато с отступами, да.

Нет. Потому что ты ТВОЙ код в следующем комментарии, а текут от этого МОИ глаза.

Возьми сделай astyle. Или не читай.

Ты не знаешь что такое стабильность? Зато 5 звёзд на ЛОРе.

Не знаешь, до чего доколебаться - доколебись до звезд.

Ошибки действительно редкие, но как правило это None

Оба раза «нет».

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

Мне просто нравится как некоторые говорят «стабильный» подразумевая что-то хорошее, а не экспотенциальный рост проблем и странных багов которые никто кроме тебя не видел (тихо решены в апстриме годы назад), при каждом обновлении на 0.0.1 чего либо (или даже 0.0.0-r1).

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

а astyle чисто опционален и никто его не упоминает во время обучения студентоты

То есть оправдание существования реализации операторных скобок отступами - это то, что кто-то хреново эрудирован и терминально ленив? Из этого можно сделать вывод, что питон это язык для тупых и ленивых?

В других языках кстати в тех же случаях прилетает assert fault либо сегфолт, в питоне просто трейс вываливается и сразу понятно где проблема.

Ну прикрути этот твой astyle в greasemonkey для лора, если в жаваскрипте разбраешься. Или под спойлер код запихай.

ЯП - это инструмент, заточенный для решения задач в какой-то определенной сфере

а как же языки общего назначения? на сколько такие языки необычны?

Что-то низкоуровневое - Си

с чего вы взяли, что Си задумывался как низкоуровневый?

сервер - PHP

0_o

слишком много расхождений вымысла с реальностью.. не буду дальше читать..

То есть оправдание существования реализации операторных скобок отступами

оправдание существования реализации операторных скобок отступами

Вон как загнул, жаваскриптёр. Оправдание твоего не отформатированного кода - это архаичный костыль из сишного конпелятора?

на питоне пишут пакетные менеджеры (portage) или установщики, парсеры сайтов, он мощнее и красивее bash.

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

Си кстати считается высокоуровневым и сегодня, как и раньше.

В те времена, когда цэ считался высокоуровневым, уровней было ровно две штуки: машинные коды с ассемблерами и всё остальное.

Двухэтажные дома тоже когда-то считались высокими. Наверное.

А сейчас иначе? Ну получили распространение интерпретаторы и вм, если только по этому признаку разделять. И то фигня какая-то получается, машинные коды то никуда не делись.

Поставь себе Pycharm / VSCode и не мучайся

Оно телепатией будет угадывать какой нужен отступ после копипаста из другого места?

Чем плохо питоновское ООП?

Примерно тем, чем было плохо ООП в php 4.

По-моему даже kwrite в kde телепатией угадывет. У тебя гном небось? Ну и vim опять же есть. Нет, у тебя наверно scintilla, да? Notepad++ какой-нибудь?

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

Алгоритмами, которые зашиты в IDE и твоей головой, если ты любитель копипасты.