Я подумал о том чего мне не хватает в Python, и что мне не нравится.
Здесь и далее под Python я имею ввиду эталонную реализацию Python — Cpython.
Дисклеймер: это мое субъективное мнение, оно может не совпадать с Вашим.
Я с удовольствием программирую на Python, но у любой технологии (языка программирования в частности) есть свои недостатки, хотя возможно Вы не согласитесь со мной.
Статья не имеет цели развести холивар. Не забывайте об этом при написании комментариев).
1. Отсутствие const
Это наверное один из самых первых пунктов, который приходит в голову. Константы это реально удобно, они могут существенно уменьшить число ошибок в коде. Например, предположим у Вас есть число Пи и константа Pi. Возможен случай когда Вы по невнимательности перепутаете Pi, скажем, с переменной Pii и измените значения числа.
В Питоне нет поддержки констант.
Конечно, Вы можете называть переменные большими буквами и считать их константами (не изменять их).
Но проблема в том, что это не прописано в PEP8. Т.е если Вы присвоите значение переменной CONSTANT, Ваша IDE никогда не скажет Вам, что Вы делаете что-то не так.
Конечно, Вы можете использовать костыли чтобы сделать константы, например
этот класс со Stackoverflow.
2. Низкая производительность
Здесь я имею в виду производительность именно кода на Cpython. Если питоновский скрипт использует для тяжелых вычислений библиотеку на Си, то все становится гораздо быстрее.
Вся стандартная библиотека по максимуму написана на Питоне, не на Си.
С одной стороны это увеличивает ее портируемость (на альтернативные реализации вроде PyPy).
С другой стороны это существенно снижает скорость. Например, стандартный модуль json имеет простое и понятное апи, но с другой стороны значительно медленнее сторонней реализации ujson (написан на Си).
3. Отсутствие switch и цикла с постусловием
Когда я спрашивал знакомых питонистов, что им не хватает в языке многие сказали, что конструкции switch и цикла do/while как в Си подобных языках.
#switch вместо кучи if
switch a:
case 1:
b=1
case 2:
b=3
default:
b=5
#вместо этого приходится писать while True: if not условие:break
do:
print(i)
while i<5
Примеры, понятное дело выдуманные, но согласитесь, что это приятнее.
4. Обратная совместимость не всегда хороша
Иногда нарушение обратной совместимости бывает нужным чтобы сделать что-то более понятным и удобным, но если отличий очень много, как между 2 и 3 версией, то это боль.
Конечно, можно без особых проблем переписать скрипт со 2 версии на 3, благо есть официальное руководство.
Но согласитесь, неприятно, что для работы всех программ на Питоне нужно иметь 2 интерпретатора: 2 версии и 3. По-прежнему число проектов на 2 версии велико.
Кстати, в 4 версии Python обратную совместимость вроде как опять сломают (PEP401)
Оператор != заменяют на <>
Вместо того чтобы писать 1!=1 мы будем писать 1<>1
Опробовать новый оператор можно уже сейчас:
from __future__ import barry_as_FLUFL
print(barry_as_FLUFL) #_Feature((3, 1, 0, 'alpha', 2), (4, 0, 0, 'alpha', 0), 262144)
1!=1 #выбросит SyntaxError
UPD: Умные люди в комментариях сказали, что это первоапрельская шутка от разработчиков. Ничего не могу сказать по этому поводу, в PEP ничего не было сказано про шутку.
Но несмотря на это, в Python все равно множество обновлений привели к нарушению обратной совместимости, например версия 3.7
5. Спорные пункты
К ним можно отнести GIL и синтаксис Питона.
Кому-то не нравится синтаксис тем что он не похож на сишный.
Однако, как правило, чем больше кодишь на питоне, тем больше нравится его специфика)
По поводу GIL многие скажут, что это однозначный минус, т.к ограничивается параллельность вычислений.
Могу сказать, что основные причины использования GIL это:
Однопоточные сценарии выполняются значительно быстрее, чем при использовании других подходов обеспечения потокобезопасности;
Простая интеграция библиотек на C, которые зачастую тоже не потокобезопасны;
Простота реализации.
Кстати, есть реализации Python без GIL, например IronPython, Jython.
В Cython можно выключать GIL.
На этом все.
А что Вы хотели бы видеть в Питоне и чего Вам не хватает?
Пишите Ваше мнение в комментариях.
Комментарии (114)
Yermack
17.03.2019 14:30+8Надо было тщательней подготовить материал: добавить сравнений с другими языками и описать менее очевидные проблемы, ждущие начинающих (Ведь статья предназначено для
нихнас?) Просто все эти пункты, кроме второго — вопросы удобства и, например, такого начинающего как я не пугают. Да и язык используется больше как связка для инструментов или скрипт-клей для существующих решений. Если честно, эта тема больше похожа на накрутку просмотров и заправку для холивара
Enmar Автор
17.03.2019 14:34-1Спасибо за отзыв!
Мне кажется я все расписал.
В 1 пункте написано, чтоКонстанты это реально удобно, они могут существенно уменьшить число ошибок в коде
В 3 пункте все в спойлере)
В 4Но согласитесь, неприятно, что для работы всех программ на Питоне нужно иметь 2 интерпретатора
danfe
17.03.2019 15:30+1Но согласитесь, неприятно, что для работы всех программ на Питоне нужно иметь 2 интерпретатора
Справедливости ради, это становится всё меньшей проблемой; субъективно уход со второй версии заметно ускорился последнее время, причем связано это имхо не с понуканиями типа «ну давайте перелезайте уже, мы вам и скрипт написали», а главным образом с тем, что все новые клёвые фишки стандартной библиотеки доступны только в 3.x (посмотрите, например, насколько subprocess стал гибче и приятнее в использовании).
Та же функцияprint()позволяет удобно, по-простому (если не хочется заморачиваться с модулями логирования) реализовать verbose output:
verbose_print = lambda *a, **k: None for o, a in opts: ... elif o == '-v': verbose_print = printEnmar Автор
17.03.2019 15:37-3Что питон 3 является прорывом и замечательным, никто не спорит.
Но в любом случае проектов на 2 еще достаточно.
Во дистрибутивах линукса все еще устаналивают 2 версии.danfe
17.03.2019 15:45Пока да, но если еще год назад это действительно было проблемой (в каких-то дистрибутивах дефолтной была одна версия, в других — другая, в третьих вообще только вторая пакетирована), то сейчас можно сразу целиться на третью и особо не переживать. FreeBSD собирается в портах сделать 3.6 по умолчанию в апреле, после того как отбранчится 2019Q2.
geisha
18.03.2019 02:59Если честно, эта тема больше похожа на накрутку просмотров и заправку для холивара
Капитан стоит в сторонке и согласно кивает.
AN3333
17.03.2019 14:32-1Главное что мне не нравится это невыполнение обещаний.
Питон был заявлен как скриптовый язык. В моем понимании скриптовый язык это в первую очередь язык для склейки написанного на других языках. Остальное вторично.
Когда Питон начал становиться популярным вставить его в свою программу, это была головная боль. Люди начали писать специальные инструменты, например, для генерации интерфейсов с С. Потом эти инструменты стали плодиться как мухи.KonkovVladimir
17.03.2019 14:46Питон был заявлен как скриптовый язык. В моем понимании скриптовый язык это в первую очередь язык для склейки написанного на других языках. Остальное вторично.
Не подскажите кем это было заявлено? Гвидо с вами не согласен.
«The Python programming language started as a successor of Perl to write build scripts and all kind of glue software.» ALL LIES!
© Guido van Rossum
Простейший интерфейс для написания модулей на C/C++ для python был и есть стандартной поставке docs.python.org/2/extending/extending.html, так-же как и возможность «вставить его в свою программу» — docs.python.org/2.7/extending/embedding.html
Лично мне не нравится в Python отсутствие возможности перегрузки конструктора класса.AN3333
17.03.2019 15:19+2Простейший интерфейс для написания модулей на C/C++ для python был и есть стандартной поставке
А вы пробовали воспользоваться этой возможностью?
Я сразу пришел в ужас и даже не пытался. Видимо и многие другие тоже, поскольку альтернативы сразу стали расти как грибы.KonkovVladimir
17.03.2019 15:46+4пробовал — очень приятно и гибко, удобнее, чем все эти грибы, из минусов:
- нужно уметь программировать на С/C++
- нужно прочесть документацию
- обратная несовместимость с 2-й версией
AN3333
17.03.2019 15:29Не подскажите кем это было заявлено? Гвидо с вами не согласен.
«The Python programming language started as a successor of Perl to write build scripts and all kind of glue software.» ALL LIES!
© Guido van Rossum
Знаете, я конечно не вспомню что именно было написано в те времена на сайте Гвидо, однако, у меня сложилось четкое впечатление что это именно скриптовый язык.
Я попробовал сделать Питоновый интерфейс для своей программы, ужаснулся и больше в эту сторону не смотрел.
Даже интересно, а как он его позиционировал?splav_asv
18.03.2019 00:54Простите, а в чем ужас? Вроде бы по работе регулярно обертки делаю с помощью Cython. Или вы что-то другое имеете в виду?
Ktulhy
17.03.2019 15:41+2В 2.7 как минимум было
Python Metaclasses
С их помощью вы можете жонглировать всеми атрибутами класса, методами, и вообще вернуть, например, другой класс.
Можно сделать Singletone с помощью метаклассов, а можно, например, Django ORM какой-нибудь.AN3333
17.03.2019 15:492,7 это современность — 2013 год.
Ничего разумного не было по крайней мере первые несколько лет. Не только для плюсов, но и для С.Ktulhy
17.03.2019 15:52Совершенно не понял ваш комментарий.
Метаклассы были и в 2.7, в 3+ их сделали более приятными. Что значит «ничего разумного не было первые несколько лет»?
etho0
17.03.2019 15:43+2отсутствие возможности перегрузки конструктора класса.
Насколько я понимаю, вы врете. Такая возможность есть. В любом случае напишите пример клиентского кода который использует эту возможность, и я вам покажу как этого добиться на питонеKonkovVladimir
18.03.2019 04:49Перегрузка конструктора означает (на примере Java), что существует такой синтаксис в языке, позволяющий создать два конструктора с разным набором аргументов и что-то мне подсказывает что врете вы, поскольку в python подобного синтаксиса не существует.
Возможно вы имели ввиду набор костылей и соглашений, позволяющий эмулировать такое поведение в классе и при его наследовании, однако речь была не про костыли.
barker
18.03.2019 08:16Нельзя создать два конструктора с разным набором аргументов, потому что нельзя создать два метода с разным набором аргументов. Задача решается просто другим способом, чем в c++/java/… За больше чем 10 лет у меня ни разу не было каких-то проблем с этим.
Причём скорее всего речь про __init__, который строго говоря и не конструктор совсем с точки зрения того ООП, который вы сами имеете в виду, а просто обычный (хоть и магический) метод уже готового сконструированного инстанса.KonkovVladimir
18.03.2019 08:37Любая задача решается с помощью «костылей», например замена case-оператора в python (тут уже было много примеров) или ООП на ФОРТРАН, причем у програмистов на ФОРТРАН «не возникает проблем» писать код без ООП, поскольку фортран Тьюринг-полный язык и там можно написать любую программу написанную на другом Тьюринг-полном языке.
Топик-стартер и я обсуждаем лишь удобства или неудобства разных подходов и синтаксических конструкций.
kammala
17.03.2019 14:56+4мне кажется, что PEP-401 немного рановато вспоминать(две недели еще б подождать).
Anton23
17.03.2019 15:20А зачем вообще это делать?
Оператор != заменяют на<>
dopusteam
17.03.2019 15:29+1
ximik666
17.03.2019 15:00+2Начинал изучать программирование ещё на Pascal/Delphi6(одна из дисциплин в ВУЗе), всегда бесило описание каждой переменной. Но потом, когда программы становились сложнее и ошибки типов выходили уже на этапе компиляции, стал понимать, что описание переменных не так уж и плохо. Сейчас немного пишу на Python(не более 1500 строк кода программа) и приходится типы переменных держать в голове, что напрягает. Даже не могу представить, что творится с переменными в больших программах на Python и как всё это отслеживать. Считать ли это недостатком языка — каждый решает сам, по мне так просто особенность.
Enmar Автор
17.03.2019 15:03+5А Вы знали, что в Питоне есть такая фича как анатоции типов?
Ktulhy
17.03.2019 16:02+3Непонятно, за что минусуют человека.
Да, аннотации типов не гарантируют того, что функция вернёт именно этот тип / аргумент будет именно этого типа.
Python на то и динамический язык, чтобы не давать никаких гарантий на счёт типов :)
Зато аннотации поддерживаются, например, pycharm, который, если вдруг увидит неправильное использование типов — начнёт ругаться, что меня, например, не раз спасало от потенциальных ошибок, как раз таки из-за того, что все типы в голове не уместить.
0xd34df00d
17.03.2019 16:39+4Потому что с таких аннотаций типов толку мало, и сравнивать их с полноценными статическими системами типов странно (особенно — с действительно мощными системами типов).
Ktulhy
17.03.2019 16:52Давайте так.
У человека есть проблема — он не может удержать в голове типы и работу с ними.
Есть инструмент — аннотация типов, которая хоть и не решает всю проблему, но помогает избежать некоторое количество ошибок и сэкономить достаточно много времени.
Уже есть сподвижки (аля MyPy) для того, чтобы сделать Python более типобезопасным.
Не вижу в этом абсолютно ничего плохого.
Язык динамически типизируемый (как и JS), и, кто знает, что в будущем случится с аннотациями типов.0xd34df00d
17.03.2019 16:57+3Конечно, плохого в этом мало, но я ведь не говорю, что это плохо. Это просто слабый инструмент в каком-то смысле.
Ktulhy
17.03.2019 17:10Интересно, а почему вы считаете, что он слабый, и что необходимо, чтобы он стал сильным?
danfe
17.03.2019 17:42+3Думаю, дело в том, что [любому] человеку, который понимает всю силу полноценных статических систем типов, все эти аннотации — lipstick on a pig.
Ktulhy
17.03.2019 17:44Как в динамически типизируемом языке реализовать полноценную статическую систему типов?
0xd34df00d
17.03.2019 17:50+3По-простому — никак, и именно поэтому все эти инструменты никогда не достигнут желаемого уровня гарантий без существенного ограничения функциональности нижележащего безтипового языка.
Не по-простомуЕсли у вас есть полноценные зависимые типы и сигма-типы, то динамическую типизацию можно делать через сигма-тип из переменной-типа и терма соответствующего типа.
0xd34df00d
17.03.2019 17:46+1Потому что он не делает тех же проверок до выполнения программы, и потому что его выразительная сила несравнима с ?P?, например.
lgorSL
18.03.2019 01:35В текущем виде аннотации питона напоминают набор костылей и жалкую пародию на статически типизированные языки, сочетая в себе многословность указания типа с небезопасностью исполнения динамических языков.
- Сторонние библиотеки типа numpy или keras аннтоациями не обладают, так что pycharm не справляется с анализом и много ошибок не ловит.
- Что ещё хуже, сторонние библиотеки с самого начала писались с учётом динамической типизации, так что описать происходящее в типах может быть сложно.
Например, вместо нормального набора нескольких перегруженных методов используется один метод с целой портянкой аргументов со значениями по-умолчанию, а если вдруг укажешь какую-нибудь несовместимую пару флагов, код упадёт. Возвращаемый тип может зависеть от входных аргументов или даже от фазы Луны. - Я не нашёл удобного способа аннторировать сторонний код (тот же numpy)
- Не смотря на то, что аннотации пишутся "для программиста", они могут сделать скрипт нерабочим. Например, при определении методов класса сам класс ещё не определён, и если в аннотации написать не строку с именем класса, а само имя, то интерпретатор сочтёт это страшной ошибкой и код не запустит.
- Аннотации можно использовать не везде — например, в лямбдах их сильно не хватает, и pycharm часто не справляется.
rSedoy
17.03.2019 15:05+2Список каких-то несущественный проблем. Ну и про «Медленная производительность», это не то что проблема, это особенность всех подобных ЯП.
Enmar Автор
17.03.2019 15:13-1Дисклеймер: это мое субъективное мнение, оно может не совпадать с Вашим.
Но согласитесь, что медленная производительность это в любом случае плохо.dopusteam
17.03.2019 15:19+3Согласитесь, что 'медленная производительность' это относительное понятие?
Enmar Автор
17.03.2019 15:23-2Скажу конкретнее.
Медленная производительность это, скажем, медленность io.
Например node js гораздо быстрее пишет в файл (бенчмарки в интернете есть).dopusteam
17.03.2019 15:26+1Но помимо производительности ещё есть много факторов при выборе языка.
Плюс то, что нода пишет быстрее, не значит что питон медленный, такой вывод нельзя сделать, можно сделать вывод только что питон медленнее ноды пишет в файл
Suvitruf
17.03.2019 15:55И тем не менее, на ноде с диском лучше не работать. Особенно, если речь про отдачу статики )
Anton23
17.03.2019 15:21Дисклеймер: это мое субъективное мнение, оно может не совпадать с Вашим.
Т.е., вы предполагаете, что медленная производительность может кому то понравиться?Enmar Автор
17.03.2019 15:29Это я про все вобщем)
А вообще данная фраза нужна была для того чтобы сдержать потенциальную волну хейтеров, которые написали бы что, скажем, отсутствие switch это вообще круть.Ktulhy
17.03.2019 15:57+2Давайте честно.
switch — это рассадник багов (забыл поставить break! или не забыл?...), который в очень редких случаях даёт немного удобства за счёт того, что можно объединить несколько веток выполнения.
Альтернатива с if-elif-else намного, на мой взгляд, очевиднее, безопаснее (в том плане, что не нужно думать про break) и предоставляет такой же функционал (case-default).
Так что отсутствие switch — это реально круто, потому что порог вхождения в язык ниже и со switch-case было бы очень много ошибок.Neyury
17.03.2019 16:12+4Есть еще один интересный вариант, это switch в golang, где нет break, а есть fallthrough, с помощью этого оператора явно указывается, что нужно провалиться в следующий блок. Если добавлять switch, то этот вариант мне нравится больше, хотя по поводу switch в python — это и правда излишне.
rSedoy
17.03.2019 15:26+4Про субъективность этого вам уже ответили, ну и плюсом — не тянут эти четыре «параграфа» на статью для Хабра, просто «голая» информация, надо было добавили чего-нибудь интересного или каких-нибудь нюансов.
QtRoS
17.03.2019 15:38+3Производительность может быть хорошой, плохой, низкой, высокой, но не медленной. Скорость работы/выполнения операций может быть медленной.
CaptainFlint
17.03.2019 16:22+2Если уж занудничать, то и скорость не может быть медленной. Медленным может быть выполнение, а скорость может быть низкой/высокой.
danfe
17.03.2019 15:38+1Список каких-то несущественный проблем.
Мне кажется, автор просто еще не набрался достаточного питоньего опыта, оттого его отсутствиеswitchда прочие мелочи и напрягают. :-) Ничего, со временем столкнется и со сложностью деплоймента, невозможностью по-простому получить экзешник, вкусит «прелести» динамической типизации и т.д.
ligor
17.03.2019 15:39А почему тогда его в большинстве своем используют в ИИ и МЛ?
Enmar Автор
17.03.2019 16:24-2Эта цитата для Вас.
Я с удовольствием программирую на Python, но у любой технологии (языка программирования в частности) есть свои недостатки, хотя возможно Вы не согласитесь со мной.
kzhyg
17.03.2019 16:31+4Зачем вы писали статью, если на любые вопросы у вас один ответ — «таково моё мнение, не спорьте с ним»?
Enmar Автор
17.03.2019 16:56-4Ну почему же, я как мне кажется описал реальные хотелки о которых думали многие питонисты.
Разве вы не мечтали о большей производительности?
А чтобы обратная совместимость была 100%?Ktulhy
17.03.2019 17:14+1Давайте я покажу, «о чём думали многие питонисты»:
Про медленную производительность уже несколько раз написал ниже
Enum/constants
Switch Case
Про обратную совместимость
Ktulhy
17.03.2019 17:21+1А чтобы обратная совместимость была 100%?
… и язык превратился бы в такого же монстра, как и C++, и вряд ли бы мы увидели Python 3.7 с тем количеством фич, что сейчас. Отказ от неудачных решений позволяет языку развиваться быстрее.
Я готов при переезде на python4 запустить какой-нибудь3to4, и спокойно работать на следующей версии языка.
danfe
17.03.2019 17:22+4[Я], как мне кажется, описал реальные хотелки, о которых думали многие питонисты.
Нет, вы описали хотелки неофита, который видел/привык к ним в других языках и пока просто не знает (или не понимает), почему они deliberately не были реализованы в петоне.
Разве вы не мечтали о большей производительности?
Нет; производительности петона вполне достаточно для типичных задач. Там, где она таки нужна, есть известные способы её повысить. Вы же сами пишете, что питон вам нравится именно как язык, на котором очень быстро можно разработать что-либо, — так вот, ради скорости разработки зачастую приходится жертвовать скоростью работы программ. Для бескомпромиссной производительности существуют другие языки.
А чтобы обратная совместимость была 100%?
К сожалению, мы живем не в идеальном мире. Это довольно странная хотелка, чтобы о ней говорить. Да, хотели бы; на 100%, увы, не получается. End of story.
asd111
17.03.2019 23:00В ИИ и мл основное требование это скорость проверки разных теорий т.е. есть задача и нужно проверить много разных подходов и для этого нужен язык который позволяет быстро писать и не мучиться с синтаксисом. Плюс у питона много готовых библиотек для математики и обработки данных.
Ktulhy
17.03.2019 15:40+6Давайте я расскажу вам про Enum и вы не будете писать глупости о том, что в Python нет констант :)
По поводу скорости — пожалуйста:
Pypy
Cython
Switch же спокойно реализуется через что-то подобное:
def action_a(): ... def action_b(): ... def action_default(): ... choise = {'a': action_a, 'b': action_b} choise.get(value, action_default)()
Для маленьких методов естественно намного удобней if-elif-else, для больших методы и словарь самое то.
Удачи в изучении языка!Enmar Автор
18.03.2019 09:17Глупости, что в питоне нет констант.
Так их и нет, имеется ввиду нормальные констатны, которые объявляются ключевым словом.
Punk_Joker
17.03.2019 15:53Оператор != заменяют на<>
Писал на Python для Symbian. основан вроде как на версии 2.1 или 2.4, так там я так и писал <>
vilgeforce
17.03.2019 16:09+1О нет! Возвращение <> в современные языки!!! И на чем мне теперь скрипты писать? :-(
Deepwalker
17.03.2019 16:241. json в стандартной библиотеке питона имеет сишную реализацию – https://github.com/python/cpython/blob/f19447994983902aa88362d8fffe645f1ea2f2aa/Modules/_json.c и фалбек на чисто питоновскую, если сишная по каким либо причинам не доступна.
2. switch с break? Но зачем же такой ад тащить в язык? Может еще и строки с null терминатором? Было бы неплохо иметь паттерн матчинг, и вот там оно возможно и пригодилось бы, но с этим есть определенные проблемы.
3. const был бы хорош, если бы он не был как в js, а действительно фризил объекты. К сожалению такую опцию втащить в текущий язык будет сложновато. Тут можно было бы что-то с mypy поколдовать, чтобы он ставил метку, что переменная не переменная.
С сожалением вынужден заметить, что прежде чем начинать проектировать добавки к языку, надо иметь крепкую теоретическую подготовку. Ну и проверять факты.Ktulhy
17.03.2019 16:29Enum не позволяет переопределять значения:
>>> from enum import Enum >>> class A(Enum): ... a = 1 >>> A.a = 4 Traceback (most recent call last): File "<input>", line 1, in <module> File "/usr/lib/python3.7/enum.py", line 385, in __setattr__ raise AttributeError('Cannot reassign members.') AttributeError: Cannot reassign members.
Enmar Автор
17.03.2019 16:51+1По поводу 2 я просто сказал, что switch было бы здорово иметь в языке.
А пример был как на си, только с питоновскими отступами.Ktulhy
17.03.2019 16:54+1Вопрос не потроллить, мне правда очень интересно.
Можете привести пример, где реально нужен switch-case-default, по вашему мнению? Какую логику пытались реализовать, что вам очень сильно не хватило вышеозначенной конструкции?
ef_end_y
18.03.2019 01:47таких задач достаточно. Например, команда -> действие. '+': return a + b; '-': return a — b. Реальный боевой пример искать влом, но бывает необходимость время от времени. В любом случае, switch сам по себе не смотрится коряво, почему бы его не включить?
saluev
17.03.2019 16:31+8Производительность не бывает медленная. Программа бывает медленная, а производительность бывает низкая!
nonname
17.03.2019 16:32-1Все эти плюсы-минусы очень индивидуальное.
Для меня например Python оказался очень удобным языком. В основном пишу rest-сервисы для Dev-ops целей. Чаще всего я не читаю старый код, поэтому проблема 2й версии вообще не актуальна. Производительности хватает более чем, пока даже без применения асинхронности, С-библиотек, использую треды или балансировку между однопоточными экземплярами в контейнерах, даже проблема с GIL не актуальна. switch\const вообще как по мне вкусовщина, ну да немного рябит в глазах от if\elif… но привыкаешь и перестаешь обращать на это внимание. const разрешается обычно через кортежи.
Взамен мы получаем отличный инструмент, при помощи которого можно очень быстро построить любой сложности компонент pipelin'а, будь то ETL задача или часть CI\CD процессов, автоматизация задач эксплуатации, автотестирования.
saipr
17.03.2019 16:33Когда я спрашивал знакомых питонистов, что им не хватает в языке многие сказали, что конструкции switch как в Си подобных языках.
Удивительно то, что python очень многое заимствует из tcl, а switch почему-то не взял.
В tcl ваш пример switch выглядит практически как у вас:
switch $a { 1 { set i 2 } 2 { set i 3 } default { set i 4 } }
CaptainFlint
17.03.2019 16:34-4Я на питоне пишу мало, но когда приходится, ругаюсь по таким поводам:
1. Отступы. Ну да, много копий сломано на эту тему, но для меня это недостаток.
2. Дурацкая форма тернарного оператора (value1 if condition else value 2). Сишная форма (condition? value1: value 2) моими глазами парсится проще и быстрее.
3. Невозможность присвоения внутри условия. Пару раз надо было написать код вида:
Но поскольку так нельзя, то эта последовательная цепочка превращается в дерево вложенных if-ов.if (m = re.match('regexp1', str)): do_something_with(m) elif (m = re.match('regexp2', str)): do_something_else_with(m) elif …danfe
17.03.2019 16:45+4Невозможность присвоения внутри условия.
И это дико круто. За это многие паскаль по молодости не любили, а с возрастом наоборот, оценили*. :-) В петоне, кстати, из-за этого (PEP 572) целая драма случилась.
*) Помните старую историю про попытку вставить в код Linux бэкдор? Вот оно, зло присваиваний внутри условия.
Tanner
17.03.2019 17:02PEP401 ? это первоапрельская шутка, если вдруг кто не понял.
Остальные пункты ? тоже несерьёзно. Не хватает проблематики. Какую именно задачу решитconstилиswitch-case? В чём недостаток нынешних best practices? С этого надо было начинать.
lxsmkv
17.03.2019 18:18+2Sтатью нужно было назвать «Отличия Python и C».
А то получилось «Слон замечательный, и я его люблю. Только, жалко, у него нет шерсти как у кота. А еще он большой и кушает много».
Ведь очевидно, что все создавалось с определенными парадигмами в голове, и оно не может быть хуже, оттого, что человек или не понимает этих парадигм, либо не согласен с ними.
В pep-3103 описано как минимум четыре варианта синтаксиса для switch. И описаны предпочитаемые способы решения задачи, для которой в других языках часто используется switch-case.
Alexey2005
17.03.2019 18:48+2Лично меня напрягает не сам язык, а его инфраструктура, в частности работа с зависимостями. Как надо поставить какой-либо компонент, так вечно вываливаются проблемы, особенно если этот компонент подразумевает наличие пачки символьных ссылок на какие-нибудь *.lib.so. Тут сразу такое шаманство начинается, что в жизни больше не захочешь с этим языком связываться.
tyomitch
17.03.2019 18:57-2Никто почему-то не упомянул, что Python — это опенсорс.
Кому недостаёт каких-нибудь фич, тот может делать свой собственный форк со switch и const, набирать сторонников и слать PR в мастер.danfe
17.03.2019 19:12+3Слушайте, ну это несерьезный аргумент. Очевидно, что проект такого масштаба невозможно форкнуть, добавить пару (весьма при этом спорных) фич и надеяться, что твой форк внезапно станет интересен настолько, что хотя бы один популярный дистрибутив добавит его в свой репозиторий как альтернативу апстриму. Таких примеров, если они вообще есть, — единицы; я навскидку не могу вспомнить ни один.
tyomitch
17.03.2019 19:22PR с фичами, тем не менее, принимают активно.
Только так фичи в языке и появляются.danfe
17.03.2019 19:28С этим я не спорю, но слать PR'ы в существующий проект это совсем не то же самое, что поддерживать свой форк (если, конечно, не считать свой локальный клон репы проекта форком).
Форк — это когда ты говоришь, мол, «нам не по пути с вами, чуваки» по тем или иным причинам (как, например, OpenBSD отпочковалась от NetBSD из-за персональных разногласий, или DragonFly от FreeBSD 4.8, но тут скорее всё-таки из-за технических, хотя там была своя драма).
MSC6502
17.03.2019 19:04-1Ключевое слово «скриптовый». Т.е. его место где-то около bat-файлов, power shell, bash и проч. Когда научится компилировать в найтивный код, тогда добро пожаловать в семью Языков Программирования, а не скриптописательства. И да, выпускаешь язык
программированияскриптописательства, будь добр сразу сделать к нему нормальную IDE с отладчиком.tyomitch
17.03.2019 19:10Java — тоже не язык программирования, раз компилируется не в нейтив?
MSC6502
17.03.2019 22:46-4Увы, да. Весь интернет держится на средстве обработки данных, прототип которого был сварганен за пару недель на коленке just ad usum internum, что называется. А потом вырвался в мир, и всё, его не остановить.
akhalat
17.03.2019 19:19+2Что просто вымораживает после си-подобных языков, так что границы блока определяют по отступам — числу пробелов, причем заменять их табуляциями не катит. На практике очень неудобно, когда копируешь код из одного шелла в другой и отступы могут сбиваться, или когда копируешь большой кусок с кучей дефов и начинает ругаться с определенного момента, хотя если разбить этот кусок на маленький и скармливать по кусочкам — ошибок нет. Почему нельзя было сохранить православные фигурные скобочки для этих целей…
danfe
17.03.2019 19:24+1Зато знаете, насколько проще читать код какого-нибудь стажера или человека с альтернативным чувством прекрасного без необходимости прогонять оный через бьютифаер, и сколько времени это экономит? ;-)
DollaR84
17.03.2019 19:57+1Это принуждает разработчиков писать удобочитаемый код. В си-подобных языках хоть и есть фигурные скобочки, но все нормальные кодостайлы требуют оформлять код отступами для удобства чтения.
akhalat
17.03.2019 21:10+1Да, уверяю вас, и с сохранением отступов можно такую лапшу наварнякать, что прочитать не сможете. Главное ведь логика, стоящая за кодом. Но необходимость соблюдать отступы приводит к потере времени, когда надо бы быстро скопипастить код в шелл, а при процессе дико начинает съезжать разметка. Или когда нельзя кинуть код целиком, а приходится скармливать по частям из-за мнимых проблем с выравниванием.
оформлять код отступами для удобства чтения.
Отступы можно делать пробелами, можно табами, но питону, блин, подавай только пробелы. а текстовый редактор автоматически выраванивает табами при переносе строки, даже если предыдущая строчка была «отступлена» по пробелам. И начинается квест по автозамене… Не говоря уже о том, что конец блока не оканчивается никаким кодовым словом БЕЗ выравнивания, строка с return так и остается висеть в воздухе, и редактор так и продолжит штамповать эти новые строки с выравниванием, пока принудительно его не остановишь, что-то напечатав с самого начала строки. А питону эти пустые строки с выравниванием после ретурна опять не нравятся и начинает ругаться, ему ведь подай пустую строку без выравнивания после конца блока… Или когда надо скопировать команду из шелла выше и нечайно защепляешь ее вместе с лидирующим пробелом (от шелла) — и лезь вручную удаляй этот пробел.
вот куча таких мелочей, серьезно затормаживающих работу, и беситdanfe
17.03.2019 22:01Главное ведь логика, стоящая за кодом.
Всё так, но это вам, как опытному программисту, не составляет труда прокупить логику алгоритма даже за скверно отформатированным кодом. Начинающих же петон приучает не только (и не столько) к общепринятым правилам оформления, сколько к необходимости ясно и четко структурировать свои мысли (реализацию алгоритма); не случайно он стал так популярен для обучения программированию.
когда надо бы быстро скопипастить код в шелл, а при процессе дико начинает съезжать разметка.
У меня ничего не съезжает; возможно, у вас что-то с настройками терминала не то.
но питону, блин, подавай только пробелы.
Это неправда: второй петон допускает микс табов и пробелов (ключик-tвыдаст предупреждение,-ttошибку), третий не допускает смешивание, но допускает табы, чтобы не ломался старый код, который выровнен только табами.
DollaR84
18.03.2019 00:48Отступы можно делать пробелами, можно табами, но питону, блин, подавай только пробелы.
Я правда использую только пробелы, и в редакторе настроена автозамена таба на пробелы, но в чьем-то коде видел вполне успешно работающие табы.
Просто надо использовать либо одно, либо другое. И нельзя их смешивать, так как пробелы и табы — это разные символы.
Tremere
17.03.2019 23:27может я неправильными редакторами пользуюсь, но в pycharm и vscode у меня не было проблем с табуляцией для кода, все легко работает как надо.
а после питона я и в c++ и в c# ставлю табуляцию в коде, в зависимости от уровня вложения, чтобы это по человечески можно было прочесть
robert_ayrapetyan
17.03.2019 19:44Какая противоречивая статья, однако! +20/-20. С одной стороны, все изложенное — правда и традиционно передается из уст в уста (тот же свитч, без которого не могут сишники), с другой — все эти факты притянуты за уши (кроме производительности, которую нужно уметь приготовить в той же pandas, но справедливости ради — на любом другом языке это тоже нужно уметь).
rgs350
17.03.2019 21:48-4Я подумал о том чего мне не хватает в Python, и что мне не нравится.
С чего вы взяли, что ваше личное мнение кого-то интересует?
AcckiyGerman
17.03.2019 21:58А я бы добавил в Python встроенный тип Json с доступом к элементам как к атрибутам, через точку.
Надоело обрабатывать ответы от API как:
data["response"]["user"]["name"]
Хотелось бы:
data.response.user.name
Я знаю что есть типы с таким свойством во встроенной библиотеке, но почему-то ни один веб-фрейморк из не использует по умолчанию.
gnomeby
17.03.2019 23:17Ох, мать. Ну ладно, поехали:
Константы это реально удобно, они могут существенно уменьшить число ошибок в коде.
Реально? И как же интересно? Ошибки в коде уменьшают только тесты: юнит, функциональные и интеграционные. Всё остальное это 5%. Ну ладно, ещё pylint полезный бывает.
Но согласитесь, неприятно, что для работы всех программ на Питоне нужно иметь 2 интерпретатора: 2 версии и 3. По-прежнему число проектов на 2 версии велико.
Я гентушник. Меня напрягает 700-1000 пакетов в системе. Наличие в системе второго питона при таком расскаладе — незаметно.
GIL
Предположим завтра случилось чудо и кто-то написал без GIL соблюдая требования Гвидо по скорости, удобству и пр. Что изменится? Ничего. Потому что почти никому не нужны многопоточные приложения на питоне. Кому нужно быстрее и на питоне юзает: Stackless, asyncio и multiprocessing. Ещё можно numpy. Вообще сейчас уже принято не тредами а корутинами делать, ибо среднестатистический разработчик не осиливает треды безопасно.
И это всё?
А вас не напрягает например странные файлы __init__.py в папках?
А то что import в однозначно не говорит, есть файл с таким именем или объект определён в __init__.py.
Вообще что через символ подчёркивания сделано много подходов?
masai
18.03.2019 01:03Ожидал увидеть в статье список наподобие такого — https://github.com/satwikkansal/wtfpython :)
Sklott
18.03.2019 10:07Недавно столкнулся с необходимостью скомпилировать нативную библиотеку для Python для разных платформ и меня просто выморозило то, что на Linux нужен только gcc, а на Windows только MSVC.
Кроссплатформенная компиляция? Не, не слышали! Качай-ставь 4Гб MSVC чтобы скомпилировать 30 килобайтный C код.
Graf54r
Переходите на java, там все это есть, а еще лучше на Котлин
Правда на счет производительности тут многие поспорят
Enmar Автор
Если мне нужно будет написать приложение под андроид, то я, как и 95% людей, обязательно перейдем на яву/котлин :-) (остальные 5% будут писать на каком-нибудь kivy, я пробывал и мне не понравилось).
А так питон мне нравится именно как язык на котором очень быстро можно разработать что либо, особенно если скорость не очень критична.
mad_nazgul
Не разработать, а накидать прототип.
Который потом надо будет переписать на C :-)