Претензии хейтеров к Питону

Хм. Первый пункт решается средствами IDE/редактора кода. Там обычно есть что то вроде «reformat on paste».
А вот многострочные лябды это да. После жава мирка непривычно :)

Первых двух хватает.
1. Код где блоки выделяются скобками не ломается при потере whitespace, питоновый ломается. Согласен, что эта проблема не всегда актуальна, но когда она актуальна, начинает подгорать.
2. Ну почему в других языках GIL нет, а в питоне есть? может быть надо запускать по питономешалке на каждый пито^Wпоток? Конечно это не мешает распараллеливать код, выполняющийся не в питоне, когда питон лишь контроллирует потоки с другим кодом (например, если некоторый сервер на питоне, но запросы к БД и ресурсоёмкие операции вынесены в нативщину), но всё равно нагрузку распределяет не совсем оптимально

4) ДТ - говно by design
5) Тормозной
6) Куча говнокода из-за питономакак и низкого порога вхождения (php сurse)
7) Куча всё-на-питон фанбоев.

4) ДТ - говно by design

Это почему? Просто такой подход к типизации иногда оправдан. Если пишется некий прототип или численный эксперимент, важнее иметь возможность бысто выполнять короткие циклы разработки «набросать код -> бросить на вход тестовые данные -> отобразить результат.» Если встроенные типы данных достаточно богаты для нужд эксперимента, то и городить новые не нужно. Та же матрица, она и в Африке матрица. Просто некоторые думают о каких-то информационных системых, для которых нужно городить типы данных, заниматься обьектно-ориентировынным анализом и прочей квази-инженерией. А для иных применений все типы данных и отношений давно известны, и код их использующий, не нуждается в постоянных проверках совместимости теплого с мягким. Банально, если перемножать несовместимые по размеру матрицы, ошибка сразу вылезет на очередной быстро проводимой итерации разработки, даже раньше визуализации данных.

В Джулии тоже ДТ (с опциональной аннотацией типов).

А можно пример использования многострочной лямбды?

ООП там сбоку припёку...

Нубы всегда забывают, что Python - скриптовой язык, что накладывает на него некоторые ограничения. А потом ноют, что он не такой производительный, как C++ или Java.

Про тот же GIL написано в доках зачем он нужен. Есть потоки с GIL, есть многопроцессорность. Ну выкинут потоки, переименуют модуль multiprocessing в threading - что изменится? В jython потоки без GIL.

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

Да забей ты на этих хэйтеров чего_угодно. Это их право относиться как угодно к чему угодно. Каждому своё.

В других подобных языках тоже GIL. Если GIL выпилить, то надо обмазать все другими локами и однопоточный код становится медленней, поэтому от этой идеи отказались. Кроме того написание многопоточного кода слишком сложно для питономакаки, проще уж процессами множиться, там для этого удобное api есть.

но запросы к БД

Это операция завязанная на io, тут ничто не мешает использовать потоки или асинхронщину.

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

Как вариант :D

AdvertisingActionEntity action = withTx(() -> {
    AdvertisingActionEntity action1 = getActionByName(actionName);
    boolean b = action1.getPlugins().isEmpty();
    action1.setActive(!b);
    return action1;
});

Куча говнокода из-за питономакак и низкого порога вхождения

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

Согласен, что эта проблема не всегда актуальна, но когда она актуальна, начинает подгорать.

Эта проблема неактуальна 99% времени. Зато код легче читать, ибо скобки для чтения кода человеку не нужны. И ладно, если кодинг-стайл нормальный.

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

некоторые высказывания ЛОРовских аналитиков

не понимаю зачем принимать их всерьез. Тут большинство орет нинужна даже не прочитав описания, что уж там про попробовать. Сейчас налетят и будут орать, что «говно потому что мне так Вася из 8Б сказал»

1. копипастеры должны страдать

2. лично мне GIL никогда не мешал

3. вот лямбды - беда. локальные функции все-таки сильно смещают фокус внимания, а comprehensions никак проблему лямбд не решают

куда дели ZOPE ?

return

return в лямбдах - то еще удовольствие

куда дели ZOPE ?

[fat]в небытие, поближе к жаве[/fat]

Всё еще хуже. Некоторые орут «ДТ - нинужно!», но сами угорают по ДТ.

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

Опоздал лет на 15

Что еще?

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

сложный богатый управляющими конструкциями

Это говнокод. Надо пользоваться паттерн-матчингом.

В каком месте?

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

Очень хорошо. Я рад, что на питоне будет меньше говнокода.

1. Отступы «легко ломаются при копипасте и редактировании»

По этому заявлению легко отсеиваются те, кто на Python не писал или тупо вбрасывает.

Что еще?

Динамическая типизация, естественно.

Просто такой подход к типизации иногда оправдан.

Он не оправдан никогда, но часто его можно терпеть.

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

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

Ну почему в других языках GIL нет, а в питоне есть?

В языке Python нет GIL. В интерпретаторе CPython есть, а в языке Python - нет.

GIL. Для некоторых применений (numpy) это не проблема.

Как раз только математики и ноют из-за GIL, на моей памяти. Ну и идиоты у которых многопоточность вместо архитектуры.

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

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

Так и было задумано. Интерпретатор гарантирует тебе строгую типизацию? Гарантирует, какие тогда вопросы?

У меня следующий список претензий:

1. Python это не один язык, это два с половиной разных языка. Только утихла боль с python2/3, так появилась боль с тем, что python/asyncio это совершенно не то же самое, что python без asyncio. А ведь еще есть знатное количество асинхронного кода без asyncio (оставшаяся половина). И вот количество и качество библиотек у python/asyncio заметно уступает и python, и go.

2. Асинхронный питон имеет большое количество детских болячек и очень неприятных костылей, исторических особенностей. Писать на нем не приятно, разбираться с Exception в задачах и future вообще неприятно и больно. Банальный код разрастается в сотни раз, если делать все совсем правильно.

Ну и идиоты у которых многопоточность вместо архитектуры

Еще один не осилил потоки. У тебя процессор способен исполнять 256 потоков параллельно, давай посмотрим какой архитектурой ты его загрузишь?

мутабельность

динамическая типизация, причем плохо сделаная

отсутствие TCO и сопоставления с образцом

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

несовместимость исходников v2 и v3 без достаточных на то оснований

Подозреваю что GIL для numpy не проблема только потому, что там половина кода на c

А, да, забыл.

Постоянная утечка памяти, из-за чего вместо тредов приходится использовать multiprocess и периодически тушить инстансы

пихают открывающие скобки на отдельную строку

вообще то так намного читабельнее. я только так пишу в своих проектах

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

Для некоторых применений (numpy) это не проблема

Аргументация уровня God.

Гарантирует, какие тогда вопросы?

К кому или чему? Если к тебе, то никаких. Если к ДТ, то ее гарантии меня не устраивают.

У тебя процессор способен исполнять 256 потоков параллельно

Запалился инопланетянин.

Те, кому в питоне мешают отступы, просто должны перестать использовать notepad.exe для написания кода.

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

Ты путаешь архитектуру с оверинжинирингом и костылями.

Гил становится заметным уже на обычном спайдере в 50-60 потоков. Помогает только модуль multiprocess.

Эта проблема неактуальна 99% времени

В одноразовых хеловордах. Как только ты начинаешь рефакторить что-то больше 1KLOC проблема вылезает в полный рост.

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

И кстати это притом что потоки все время висят в ожидании i/o

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

Ты бредишь.

Doing it wrong. Use asyncio, Luke.

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

asyncio когда появился, в 3.5.х? Или имеется в виду ад что-то типа торнадо?

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

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

За копипасту кода надо платить.