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

Python 3.5 - September 13, 2015

Да любое приложение в котором много блокирующего i/o требует потоки для нормальной работы. Те же спайдеры и веб-серверы.

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

бред

Постоянная утечка памяти

че

Многострочных лямбд же не хватает лишь по началу. Потом, получше узнав язык, перестаёшь использовать даже однострочные. Они не нужны почти никогда.

Когда хейтеры покажут аналог pandas и туже скорость/простоту/гибкость работы с данными что он даёт в связке с jupyter notebook - тогда и поговорим.

Это фигня по сравнению с вебнёй в приложениях.

выбрали язык не подходящий к задаче

А ничего, что он не подходит для львиной доли задач, которые по факту с его помощью решают?

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

Понятно что ты мамкин прогромист и никогда на питоне не работал. Именно не не писал, а не работал. Любой кто хотя бы годик погрёб на питоногалере расскажет «есть проблема или нет» в самых красочных выражениях. Щас бы с дивана рассуждать о вкусе устриц...

А то что те же спайдеры в которых надо парсить html текут. Оставляешь на ночь и все, ООМ. Видимо как только появляются сложные структуры данных тут же появляются кольцевые ссылки, с которыми наивный GC питона не справляется.

Никто так спайдеры не пишет, это жутко неэффективно. На есть asyncio, до появления этого синтаксиса были корутины на генераторах, до этого были gevent, торнадо и прочее.

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

4.2. Ознакомься с тем, как работает асинхронный ввод-вывод и больше не позорься так.

Никто так не пишет именно из-за GIL. А так это самый простой и очевидный способ написания, когда есть рабочие потоки, которые что-то там скачивают и шлют данные для дальнейшей обработки в потоки-обработчики скачанного. Просто в питоне этот способ по-человечески использовать нельзя.

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

spark m8, 32 ядра x 8 потоков = 256 потоков.

Не видел, не?

Ну и к каким же задачам (которые по факту с его помощью решают) он по твоему не подходит? С аргументацией.

развитое ipc

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

Я слава Богу уже вообще перестал позориться работая с питоном. перешел на erlang где все то же самое делается не через заднее отверстие а по-человечески. И код при этом остается читаемым, как бонус.

Они ещё часто GIL путают с залоченным потоком.

С аргументацией

В сотый раз?

Ну и к каким же задачам

Любые нагруженные сервисы. В частности веб, где его критическая масса. Гуёвые приложения. ЧСХ, он даже для скриптования не слишком подходит из-за неудобной работы с пайпами и сабспроцессами.

Дело в том, что как только появляются лочащиеся потоки, сразу возникает желание сделать таких потоков много, 20, 100 или даже 1000. И тут-то и появляется во всей своей красе GIL, даже несмотря на то что потоки большую часть времени висят в i/o.

erlang где… код при этом остается читаемым

Ой вкусовщина.

Как ты можешь быть таким жирным? Это уже неприлично даже.

Как ты можешь

Мне можно.

Не надо делать 1000 потоков, для этого есть корутины и ивент-лупы.

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

В сотый раз?

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

неудобной работы с пайпами и сабспроцессами

Что там неудобного? Очень просто в тривиальных случаях, но с очень мощными возможностями если это необходимо.

Это тема про ненависть к питону. Не мешай мне негодовать.

spark m8, 32 ядра x 8 потоков = 256 потоков.

Не видел, не?

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

А, вот и пример, когда поток программы путается с потоком процессора.

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

На том и закончим тогда. Ты — фанбой. Это бесполезно.

Python превращает дистрибутив в зоопарк из разных версий Python 2, Python 3. При этом основной ударный и популярный софт на Python типа Mercurial (Hg), Ansible, Odoo там какой-нибудь – до сих пор сидит на Python 2 и никуда переходить не желает.

Это ненормально и это уберубого. Как и разные версии pip, для Python 2 и Python 3, разный набор библиотек. В общем, Гвидо жидко обосрался когда в Python 3 не добавил совместимость с Python 2. Поверьте, эта хрень Python 2 <=> Python 3 будет аукаться нам ещё несколько лет уж точно. Именно из-за такой детской болячки Python слабо применим в Enterprise-секторе. Ибо нет никаких гарантий на адекватность. Вот выйдет Python 4 и будут у нас уже целых три Python’а в системе: 2, 3 и 4 на который будут гнать всех хипстеры-обновляторы.

Как нужно было сделать правильно? Как в Java. Именно поэтому Java в Enterprise, а Python – язычок для прототипирования.

Ну и еще: ‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘статическая типизация’’’’’’’’’’’’’’’ aka костыль для линтеров и IDE. Сразу сделать язык нормальным не получилось, так будем его костылями и велосипедами подпирать. Ещё недавно было:

~> cat gvido.py 
#!/usr/bin/python3

def greeting(name: str) -> str:
    print(name)
    return name

greeting("test")
greeting(148866613)
~> ./gvido.py 
test
148866613
~> 

Сейчас вроде подфиксили.

Спасибо, я для такого питон даже не собираюсь использовать.

Тред полон хейтеров и быдлокодеров. Засим откланиваюсь.

Для этого есть green threads, которые с точки зрения программиста ничем не отличаются от потоков, а с точки зрения виртуальной машины выгдядят как наборы комманд, которые исполняются, разбрасываясь по определенному алгоритму по настоящим потокам OS. Но можно вместо очевидного и прозрачного решения придумать лишних сущносностей в виде генераторов, futures, promises и прочего.

«быдло не видя двери бьется головой в стену. Для него выпиливают люк.» (с) не мое

Норм яп для дороги, - можно компилить на андроиде...

Если ты не знал, аннотации не влияют на исполнение программы интепретатором. Об этом было сразу написано в PEP.

Именно из-за такой детской болячки Python слабо применим в Enterprise-секторе.

Что в твоем понимании Enterprise-сектор?

В него входят Facebook? Google? Яндекс?

Это проблемы конкретного говнокода, а не питона. gc умеет работать с кольцевыми ссылками, но в парсере должны быть weakref.

Для этого есть green threads

Что я и сказал в предыдущем комментарии. Это один из вариантов корутин, причём не всегда именно тот, что действительно нужен.

можно вместо очевидного и прозрачного решения придумать лишних сущносностей в виде генераторов, futures, promises

Всё ясно, ничего сложнее хеллоувордов в институте ты не писал.

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

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

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

Не распинайся, он поймёт только когда старшие на работе по рукам надают.

Газпром, РЖД, Роскосмос, Сбер

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

Помойка на помойке же.

Я работал в роскосмосе, там питон во все поля. Как и в наса, кстати.

Попы сервера окропляют чтобы быстрее работало?

Основная проблема питона - обратная совместимость.

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

Я далек от java, но видел кучу раз что код требует определенную версию jre и о проблемах миграции на новые версии даже на лоре много писали.