Недостатки питона

Я один из тех, кто проводит в Датаарте собеседования по Питону. За два года провел около пятидесяти собеседований. Я веду специальный список, в котором собираю наиболее интересные вопросы к кандидатам. Интересные – не значит сложные или такие, чтобы запутать или унизить собеседника. Цель собеседования – определить, подходит нам кандидат или нет. Интересные вопросы дают кандидату возможность выговориться, рассказать о прошлом опыте, привычках. На такой вопрос нельзя ответить однозначно да или нет. Это аналог открытого вопроса в переговорах.

Один из интересных вопросов звучит так – какие в Питоне есть недостатки? Как вы с ними боретесь?

Вопрос замечателен своей глубиной. Это значит, что на каждую ответную реплику можно задать уточняющий вопрос, продвигаясь вглубь, пока у кого-то из нас двоих не закончится запас знаний в предметной области.

Весьма дурным ответом считаю, что в Питоне нет недостатков. Кандидат расписывается в своей неопытности. Идеального языка программирования нет. Скорее, он только начал работать с Питоном и прибывает в эйфории, когда вместо 15 строчек можно сделать то же одной.

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

Когда кандидат приводит в пример какую-то слабую особенность Питона, я в первую очередь интересуюсь, в какой ситуации кандидат с ней столкнулся и как разрешил. Часто случается, что тот или иной аргумент взят с Хабра или ЛОРа, то есть не имеет отношения к реальности.

Ниже привожу потенциальные ответы и свои комментарии к ним. В конце – свою точку зрения на поставленный вопрос.

Ответ номер один – медленное быстродействие Питона. Сразу же интересуюсь, насколько медленнее, в каких именно случаях. Приходилось ли писать такой код, когда алгоритм упирается в производительность интерпретатора. На самом деле, редко кто может этим похвастаться. Питон чаще используется в вебе, а любой веб – это клубок сетевых вызовов. Типичное веб-приложение дергает чужие урлы, читает базу, лазит в мемкеш. Большая часть времени уходит на ожидание сокетов. Это сводит производительность интерпретатора к математической погрешности.

Далее, ГИЛ – глобальный замок, который не дает исполнятся нескольким тредам одновременно. Опять же, вопрос – какие задачи лучше решаются тредами? В вебе все работает на процессах. Порождение треда на каждый запрос убьет систему в два счета. ОК, в чем разница между тредами и процессами (модули Threading и Multiprocessing)? Без ответов на эти вопросы аргумент не принимается.

Строки и изменения в третьем Питоне – повсеместный Юникод. Спрашиваю, в чем были проблемы со строками во второй ветке. Как кодируется и декодируется Юникод. Сколько байт тратит UTF-8 на один символ? Какие операции быстрей – на Юникоде или на 8-битных строках? Заметил – тот, кто понимает работу со строками, исправлениям в тройке не рады.

В процессе ответа кандидат имеет полное право спросить мою точку зрения на недостатки Питона. Отвечаю примерно так.

Производительность Питона является косвенным недостатком. Столкнуться в вебе с ним практически нереально. В практике у меня был случай, когда утилита на Питоне сильно проигрывала аналогичной утилите на Си. Я пытался распарить лог Энджинкса размером в пять гигабайт. Если ngxtop сделал это за час, то другая утилита (не помню название) – за пять минут. Это тот случай, когда критические участки кода нужно выносить из Питона на Си или использовать другие утилиты.

Есть у меня претензии к оформлению кода с использованием *args, **kwargs. Сама по себе это классная штука, но некоторые используют достоинства языка себе во вред. Например, функция или конструктор принимают много необязательных параметров. Хорошим тоном будет перечислить их все в сигнатуре со значениями None. Однако, попадаются те, кто просто лепит *args, **kwargs, и внутри тела функции разбарет их вручную. В лучшем случае в докстринге указано, что можно передавать. Это ломает автокомплит, подсказки в редакторах, вынуждает читать код. Короче, выходит проигрыш в усилиях – поленившись один раз, разработчик вынуждает напрягаться других многократно.

Строки и третий Питон. Моя точка зрения здесь лаконична. Разработчик, который хорошо знает, как устроены кодировки и Юникод, не получит в тройке никаких преимуществ, наоборот – только боль. Очень часто мы работаем с 8-битными строками, сплитим, тримим, делаем замену. Да, по сути это байты, но что с того? На каждый чих переводить байты в Юникод, я считаю, глупо. В тройке потенциальные трудности со стоками спрятали в черный ящик. Оставили начинающих разработчиков в неведении, что происходит под капотом. Незнание кодировок рано или поздно выстрелит в самый неприятный момент.

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

Задавайте открытые вопросы на собеседованиях. Не провоцируйте холивар, но подталкивайте к полному, развернутому ответу. Вы больше узнаете о кандидате, он будет к вам расположен, т.к. вы – слушатель. Принять окончательное решение – брать на работу или нет – станет проще.