СоХабр закрыт.

С 13.05.2019 изменения постов больше не отслеживаются, и новые посты не сохраняются.

H Что мне не нравится в Python в черновиках Recovery Mode

Привет, Хабр!
Я подумал о том чего мне не хватает в 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 и do/while в Python
#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)
кратко о PEP 401
Все очень просто.
Оператор != заменяют на <>
Вместо того чтобы писать 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.
На этом все.
А что Вы хотели бы видеть в Питоне и чего Вам не хватает?
Пишите Ваше мнение в комментариях.
–2
~8900

комментарии (114)

0
+6 –6
Graf54r ,  
Переходите на java, там все это есть, а еще лучше на Котлин
Правда на счет производительности тут многие поспорят
0
+5 –5
Enmar ,   * (был изменён)
Если мне нужно будет написать приложение под андроид, то я, как и 95% людей, обязательно перейдем на яву/котлин :-) (остальные 5% будут писать на каком-нибудь kivy, я пробывал и мне не понравилось).
А так питон мне нравится именно как язык на котором очень быстро можно разработать что либо, особенно если скорость не очень критична.
0
+1 –1
mad_nazgul ,  
Не разработать, а накидать прототип.
Который потом надо будет переписать на C :-)
+9
Yermack ,   * (был изменён)

Надо было тщательней подготовить материал: добавить сравнений с другими языками и описать менее очевидные проблемы, ждущие начинающих (Ведь статья предназначено для них нас?) Просто все эти пункты, кроме второго — вопросы удобства и, например, такого начинающего как я не пугают. Да и язык используется больше как связка для инструментов или скрипт-клей для существующих решений. Если честно, эта тема больше похожа на накрутку просмотров и заправку для холивара

0
+2 –2
Enmar ,  
Спасибо за отзыв!
Мне кажется я все расписал.
В 1 пункте написано, что
Константы это реально удобно, они могут существенно уменьшить число ошибок в коде

В 3 пункте все в спойлере)
В 4
Но согласитесь, неприятно, что для работы всех программ на Питоне нужно иметь 2 интерпретатора
+1
danfe ,  
Но согласитесь, неприятно, что для работы всех программ на Питоне нужно иметь 2 интерпретатора
Справедливости ради, это становится всё меньшей проблемой; субъективно уход со второй версии заметно ускорился последнее время, причем связано это имхо не с понуканиями типа «ну давайте перелезайте уже, мы вам и скрипт написали», а главным образом с тем, что все новые клёвые фишки стандартной библиотеки доступны только в 3.x (посмотрите, например, насколько subprocess стал гибче и приятнее в использовании).

Та же функция print() позволяет удобно, по-простому (если не хочется заморачиваться с модулями логирования) реализовать verbose output:

verbose_print = lambda *a, **k: None

for o, a in opts:
...
    elif o == '-v':
        verbose_print = print
–3
+1 –4
Enmar ,   * (был изменён)
Что питон 3 является прорывом и замечательным, никто не спорит.
Но в любом случае проектов на 2 еще достаточно.
Во дистрибутивах линукса все еще устаналивают 2 версии.
0
danfe ,  
Пока да, но если еще год назад это действительно было проблемой (в каких-то дистрибутивах дефолтной была одна версия, в других — другая, в третьих вообще только вторая пакетирована), то сейчас можно сразу целиться на третью и особо не переживать. FreeBSD собирается в портах сделать 3.6 по умолчанию в апреле, после того как отбранчится 2019Q2.
+1
geisha ,   * (был изменён)
Если честно, эта тема больше похожа на накрутку просмотров и заправку для холивара
Капитан стоит в сторонке и согласно кивает.
–3
+1 –4
AN3333 ,   * (был изменён)
Главное что мне не нравится это невыполнение обещаний.
Питон был заявлен как скриптовый язык. В моем понимании скриптовый язык это в первую очередь язык для склейки написанного на других языках. Остальное вторично.
Когда Питон начал становиться популярным вставить его в свою программу, это была головная боль. Люди начали писать специальные инструменты, например, для генерации интерфейсов с С. Потом эти инструменты стали плодиться как мухи.
+1
+2 –1
KonkovVladimir ,   * (был изменён)
Питон был заявлен как скриптовый язык. В моем понимании скриптовый язык это в первую очередь язык для склейки написанного на других языках. Остальное вторично.

Не подскажите кем это было заявлено? Гвидо с вами не согласен.
«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 отсутствие возможности перегрузки конструктора класса.
+2
AN3333 ,  
Простейший интерфейс для написания модулей на C/C++ для python был и есть стандартной поставке


А вы пробовали воспользоваться этой возможностью?
Я сразу пришел в ужас и даже не пытался. Видимо и многие другие тоже, поскольку альтернативы сразу стали расти как грибы.
+4
KonkovVladimir ,   * (был изменён)
пробовал — очень приятно и гибко, удобнее, чем все эти грибы, из минусов:
  • нужно уметь программировать на С/C++
  • нужно прочесть документацию
  • обратная несовместимость с 2-й версией
–5
AN3333 ,  
Это вы о чем? О современном Питоне? Речь не о нем.
0
+1 –1
AN3333 ,  
Не подскажите кем это было заявлено? Гвидо с вами не согласен.
«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

Знаете, я конечно не вспомню что именно было написано в те времена на сайте Гвидо, однако, у меня сложилось четкое впечатление что это именно скриптовый язык.
Я попробовал сделать Питоновый интерфейс для своей программы, ужаснулся и больше в эту сторону не смотрел.

Даже интересно, а как он его позиционировал?
0
splav_asv ,  
Простите, а в чем ужас? Вроде бы по работе регулярно обертки делаю с помощью Cython. Или вы что-то другое имеете в виду?
+2
Ktulhy ,   * (был изменён)
В 2.7 как минимум было
Python Metaclasses
С их помощью вы можете жонглировать всеми атрибутами класса, методами, и вообще вернуть, например, другой класс.
Можно сделать Singletone с помощью метаклассов, а можно, например, Django ORM какой-нибудь.
0
AN3333 ,   * (был изменён)
2,7 это современность — 2013 год.
Ничего разумного не было по крайней мере первые несколько лет. Не только для плюсов, но и для С.
0
Ktulhy ,  
Совершенно не понял ваш комментарий.
Метаклассы были и в 2.7, в 3+ их сделали более приятными. Что значит «ничего разумного не было первые несколько лет»?
0
AN3333 ,  
Версия 2.7 это не рождение Питона. Питон возник значительно раньше 2013 года.
0
Ktulhy ,  
Покажите место, где я сказал, что Python начался с версии 2.7 :)
Я про то, что возможность переопределять конструктор класса точно была в версии 2.7, а глубже я не копал.
–3
AN3333 ,  
Тогда зачем вы мне отвечаете. Легко заметить что я писал о другом.
+1
Ktulhy ,  
Пожалуйста, в таком случае, пишите ответ к нужному комментарию (подсказка — надо было ответить на комментарий уровнем выше). Вы вносите путанницу в обсуждение.
+1
+2 –1
etho0 ,  
отсутствие возможности перегрузки конструктора класса.

Насколько я понимаю, вы врете. Такая возможность есть. В любом случае напишите пример клиентского кода который использует эту возможность, и я вам покажу как этого добиться на питоне
+1
KonkovVladimir ,  
Перегрузка конструктора означает (на примере Java), что существует такой синтаксис в языке, позволяющий создать два конструктора с разным набором аргументов и что-то мне подсказывает что врете вы, поскольку в python подобного синтаксиса не существует.
Возможно вы имели ввиду набор костылей и соглашений, позволяющий эмулировать такое поведение в классе и при его наследовании, однако речь была не про костыли.
0
+1 –1
barker ,  
Нельзя создать два конструктора с разным набором аргументов, потому что нельзя создать два метода с разным набором аргументов. Задача решается просто другим способом, чем в c++/java/… За больше чем 10 лет у меня ни разу не было каких-то проблем с этим.
Причём скорее всего речь про __init__, который строго говоря и не конструктор совсем с точки зрения того ООП, который вы сами имеете в виду, а просто обычный (хоть и магический) метод уже готового сконструированного инстанса.
+2
KonkovVladimir ,   * (был изменён)
Любая задача решается с помощью «костылей», например замена case-оператора в python (тут уже было много примеров) или ООП на ФОРТРАН, причем у програмистов на ФОРТРАН «не возникает проблем» писать код без ООП, поскольку фортран Тьюринг-полный язык и там можно написать любую программу написанную на другом Тьюринг-полном языке.
Топик-стартер и я обсуждаем лишь удобства или неудобства разных подходов и синтаксических конструкций.

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

мне кажется, что PEP-401 немного рановато вспоминать(две недели еще б подождать).

0
Anton23 ,  
А зачем вообще это делать?
Оператор != заменяют на<>
+1
dopusteam ,   * (был изменён)
По традиции, раз в год...
Status: April Fool!

0
mad_nazgul ,  
Чтобы как в Pascal ;-)
+2
ximik666 ,  

Начинал изучать программирование ещё на Pascal/Delphi6(одна из дисциплин в ВУЗе), всегда бесило описание каждой переменной. Но потом, когда программы становились сложнее и ошибки типов выходили уже на этапе компиляции, стал понимать, что описание переменных не так уж и плохо. Сейчас немного пишу на Python(не более 1500 строк кода программа) и приходится типы переменных держать в голове, что напрягает. Даже не могу представить, что творится с переменными в больших программах на Python и как всё это отслеживать. Считать ли это недостатком языка — каждый решает сам, по мне так просто особенность.

+6
+8 –2
Enmar ,  
А Вы знали, что в Питоне есть такая фича как анатоции типов?
+3
Ktulhy ,  
Непонятно, за что минусуют человека.
Да, аннотации типов не гарантируют того, что функция вернёт именно этот тип / аргумент будет именно этого типа.
Python на то и динамический язык, чтобы не давать никаких гарантий на счёт типов :)
Зато аннотации поддерживаются, например, pycharm, который, если вдруг увидит неправильное использование типов — начнёт ругаться, что меня, например, не раз спасало от потенциальных ошибок, как раз таки из-за того, что все типы в голове не уместить.
+3
+4 –1
0xd34df00d ,  
Потому что с таких аннотаций типов толку мало, и сравнивать их с полноценными статическими системами типов странно (особенно — с действительно мощными системами типов).
–1
+2 –3
Ktulhy ,  
Давайте так.
У человека есть проблема — он не может удержать в голове типы и работу с ними.
Есть инструмент — аннотация типов, которая хоть и не решает всю проблему, но помогает избежать некоторое количество ошибок и сэкономить достаточно много времени.
Уже есть сподвижки (аля MyPy) для того, чтобы сделать Python более типобезопасным.
Не вижу в этом абсолютно ничего плохого.
Язык динамически типизируемый (как и JS), и, кто знает, что в будущем случится с аннотациями типов.
+2
+3 –1
0xd34df00d ,  
Конечно, плохого в этом мало, но я ведь не говорю, что это плохо. Это просто слабый инструмент в каком-то смысле.
0
Ktulhy ,  
Интересно, а почему вы считаете, что он слабый, и что необходимо, чтобы он стал сильным?
+2
+3 –1
danfe ,  
Думаю, дело в том, что [любому] человеку, который понимает всю силу полноценных статических систем типов, все эти аннотации — lipstick on a pig.
0
+1 –1
Ktulhy ,  
Как в динамически типизируемом языке реализовать полноценную статическую систему типов?
+3
0xd34df00d ,  
По-простому — никак, и именно поэтому все эти инструменты никогда не достигнут желаемого уровня гарантий без существенного ограничения функциональности нижележащего безтипового языка.

Не по-простому
Если у вас есть полноценные зависимые типы и сигма-типы, то динамическую типизацию можно делать через сигма-тип из переменной-типа и терма соответствующего типа.
+1
0xd34df00d ,  
Потому что он не делает тех же проверок до выполнения программы, и потому что его выразительная сила несравнима с λPω, например.
+2
lgorSL ,   * (был изменён)

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


  1. Сторонние библиотеки типа numpy или keras аннтоациями не обладают, так что pycharm не справляется с анализом и много ошибок не ловит.
  2. Что ещё хуже, сторонние библиотеки с самого начала писались с учётом динамической типизации, так что описать происходящее в типах может быть сложно.
    Например, вместо нормального набора нескольких перегруженных методов используется один метод с целой портянкой аргументов со значениями по-умолчанию, а если вдруг укажешь какую-нибудь несовместимую пару флагов, код упадёт. Возвращаемый тип может зависеть от входных аргументов или даже от фазы Луны.
  3. Я не нашёл удобного способа аннторировать сторонний код (тот же numpy)
  4. Не смотря на то, что аннотации пишутся "для программиста", они могут сделать скрипт нерабочим. Например, при определении методов класса сам класс ещё не определён, и если в аннотации написать не строку с именем класса, а само имя, то интерпретатор сочтёт это страшной ошибкой и код не запустит.
  5. Аннотации можно использовать не везде — например, в лямбдах их сильно не хватает, и pycharm часто не справляется.
+1
+2 –1
Ktulhy ,  
3) .pyi
4) Достаточно обернуть название класса в кавычки
5) Если для лямбды нужны аннотации — то лучше сделать её обычной функцией :)
+1
+3 –2
rSedoy ,  
Список каких-то несущественный проблем. Ну и про «Медленная производительность», это не то что проблема, это особенность всех подобных ЯП.
0
+3 –3
Enmar ,  
Дисклеймер: это мое субъективное мнение, оно может не совпадать с Вашим.

Но согласитесь, что медленная производительность это в любом случае плохо.
+3
dopusteam ,  

Согласитесь, что 'медленная производительность' это относительное понятие?

–3
Enmar ,  
Скажу конкретнее.
Медленная производительность это, скажем, медленность io.
Например node js гораздо быстрее пишет в файл (бенчмарки в интернете есть).
+2
+4 –2
dopusteam ,  

Но помимо производительности ещё есть много факторов при выборе языка.


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

0
Suvitruf ,   * (был изменён)
И тем не менее, на ноде с диском лучше не работать. Особенно, если речь про отдачу статики )
0
Anton23 ,  
Дисклеймер: это мое субъективное мнение, оно может не совпадать с Вашим.

Т.е., вы предполагаете, что медленная производительность может кому то понравиться?
–1
Enmar ,  
Это я про все вобщем)
А вообще данная фраза нужна была для того чтобы сдержать потенциальную волну хейтеров, которые написали бы что, скажем, отсутствие switch это вообще круть.
+3
+4 –1
Ktulhy ,  
Давайте честно.
switch — это рассадник багов (забыл поставить break! или не забыл?...), который в очень редких случаях даёт немного удобства за счёт того, что можно объединить несколько веток выполнения.
Альтернатива с if-elif-else намного, на мой взгляд, очевиднее, безопаснее (в том плане, что не нужно думать про break) и предоставляет такой же функционал (case-default).
Так что отсутствие switch — это реально круто, потому что порог вхождения в язык ниже и со switch-case было бы очень много ошибок.
+5
Neyury ,   * (был изменён)
Есть еще один интересный вариант, это switch в golang, где нет break, а есть fallthrough, с помощью этого оператора явно указывается, что нужно провалиться в следующий блок. Если добавлять switch, то этот вариант мне нравится больше, хотя по поводу switch в python — это и правда излишне.
0
Ktulhy ,  
Умно :) И больше соответствует философии Python
Но вот честно — всегда было достаточно if-elif-else
+4
tyomitch ,  
… а когда недостаточно if-elif-else, то можно забацать словарь с лямбдами внутри.
+4
rSedoy ,  
Про субъективность этого вам уже ответили, ну и плюсом — не тянут эти четыре «параграфа» на статью для Хабра, просто «голая» информация, надо было добавили чего-нибудь интересного или каких-нибудь нюансов.
+3
QtRoS ,  

Производительность может быть хорошой, плохой, низкой, высокой, но не медленной. Скорость работы/выполнения операций может быть медленной.

+2
CaptainFlint ,  
Если уж занудничать, то и скорость не может быть медленной. Медленным может быть выполнение, а скорость может быть низкой/высокой.
+1
+2 –1
danfe ,  
Список каких-то несущественный проблем.
Мне кажется, автор просто еще не набрался достаточного питоньего опыта, оттого его отсутствие switch да прочие мелочи и напрягают. :-) Ничего, со временем столкнется и со сложностью деплоймента, невозможностью по-простому получить экзешник, вкусит «прелести» динамической типизации и т.д.
0
ligor ,  
А почему тогда его в большинстве своем используют в ИИ и МЛ?
0
danfe ,  
Потому что TensorFlow.
+4
Arseny_Info ,  
Скорее потому что numpy.
–2
Enmar ,  
Эта цитата для Вас.
Я с удовольствием программирую на Python, но у любой технологии (языка программирования в частности) есть свои недостатки, хотя возможно Вы не согласитесь со мной.
+4
+5 –1
kzhyg ,  
Зачем вы писали статью, если на любые вопросы у вас один ответ — «таково моё мнение, не спорьте с ним»?
–4
+1 –5
Enmar ,  
Ну почему же, я как мне кажется описал реальные хотелки о которых думали многие питонисты.
Разве вы не мечтали о большей производительности?
А чтобы обратная совместимость была 100%?
+1
+2 –1
Ktulhy ,  
Давайте я покажу, «о чём думали многие питонисты»:
Про медленную производительность уже несколько раз написал ниже
Enum/constants
Switch Case
Про обратную совместимость
+1
+2 –1
Ktulhy ,  
А чтобы обратная совместимость была 100%?

… и язык превратился бы в такого же монстра, как и C++, и вряд ли бы мы увидели Python 3.7 с тем количеством фич, что сейчас. Отказ от неудачных решений позволяет языку развиваться быстрее.
Я готов при переезде на python4 запустить какой-нибудь 3to4, и спокойно работать на следующей версии языка.
+3
+5 –2
danfe ,   * (был изменён)
[Я], как мне кажется, описал реальные хотелки, о которых думали многие питонисты.
Нет, вы описали хотелки неофита, который видел/привык к ним в других языках и пока просто не знает (или не понимает), почему они deliberately не были реализованы в петоне.
Разве вы не мечтали о большей производительности?
Нет; производительности петона вполне достаточно для типичных задач. Там, где она таки нужна, есть известные способы её повысить. Вы же сами пишете, что питон вам нравится именно как язык, на котором очень быстро можно разработать что-либо, — так вот, ради скорости разработки зачастую приходится жертвовать скоростью работы программ. Для бескомпромиссной производительности существуют другие языки.
А чтобы обратная совместимость была 100%?
К сожалению, мы живем не в идеальном мире. Это довольно странная хотелка, чтобы о ней говорить. Да, хотели бы; на 100%, увы, не получается. End of story.
0
0xd34df00d ,  
Потому что там его используют как клей к scipy/numpy/tensorflow.
0
asd111 ,  
В ИИ и мл основное требование это скорость проверки разных теорий т.е. есть задача и нужно проверить много разных подходов и для этого нужен язык который позволяет быстро писать и не мучиться с синтаксисом. Плюс у питона много готовых библиотек для математики и обработки данных.
+5
+6 –1
Ktulhy ,   * (был изменён)
Давайте я расскажу вам про 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, для больших методы и словарь самое то.

Удачи в изучении языка!
–1
Enmar ,  
Глупости, что в питоне нет констант.
Так их и нет, имеется ввиду нормальные констатны, которые объявляются ключевым словом.
0
Punk_Joker ,  
Оператор != заменяют на<>

Писал на Python для Symbian. основан вроде как на версии 2.1 или 2.4, так там я так и писал <>
+1
+2 –1
vilgeforce ,  
О нет! Возвращение <> в современные языки!!! И на чем мне теперь скрипты писать? :-(
0
Ktulhy ,  
А ещё goto заверните, пожалуйста!
0
Deepwalker ,  
1. json в стандартной библиотеке питона имеет сишную реализацию – https://github.com/python/cpython/blob/f19447994983902aa88362d8fffe645f1ea2f2aa/Modules/_json.c и фалбек на чисто питоновскую, если сишная по каким либо причинам не доступна.
2. switch с break? Но зачем же такой ад тащить в язык? Может еще и строки с null терминатором? Было бы неплохо иметь паттерн матчинг, и вот там оно возможно и пригодилось бы, но с этим есть определенные проблемы.
3. const был бы хорош, если бы он не был как в js, а действительно фризил объекты. К сожалению такую опцию втащить в текущий язык будет сложновато. Тут можно было бы что-то с mypy поколдовать, чтобы он ставил метку, что переменная не переменная.

С сожалением вынужден заметить, что прежде чем начинать проектировать добавки к языку, надо иметь крепкую теоретическую подготовку. Ну и проверять факты.
0
Ktulhy ,  
Enum не позволяет переопределять значения:
>>> 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.
+1
Enmar ,  
По поводу 2 я просто сказал, что switch было бы здорово иметь в языке.
А пример был как на си, только с питоновскими отступами.
+1
+2 –1
Ktulhy ,  
Вопрос не потроллить, мне правда очень интересно.
Можете привести пример, где реально нужен switch-case-default, по вашему мнению? Какую логику пытались реализовать, что вам очень сильно не хватило вышеозначенной конструкции?
0
ef_end_y ,  
таких задач достаточно. Например, команда -> действие. '+': return a + b; '-': return a — b. Реальный боевой пример искать влом, но бывает необходимость время от времени. В любом случае, switch сам по себе не смотрится коряво, почему бы его не включить?
0
Ktulhy ,  
+9
saluev ,  
Производительность не бывает медленная. Программа бывает медленная, а производительность бывает низкая!
–1
+2 –3
nonname ,  
Все эти плюсы-минусы очень индивидуальное.
Для меня например Python оказался очень удобным языком. В основном пишу rest-сервисы для Dev-ops целей. Чаще всего я не читаю старый код, поэтому проблема 2й версии вообще не актуальна. Производительности хватает более чем, пока даже без применения асинхронности, С-библиотек, использую треды или балансировку между однопоточными экземплярами в контейнерах, даже проблема с GIL не актуальна. switch\const вообще как по мне вкусовщина, ну да немного рябит в глазах от if\elif… но привыкаешь и перестаешь обращать на это внимание. const разрешается обычно через кортежи.
Взамен мы получаем отличный инструмент, при помощи которого можно очень быстро построить любой сложности компонент pipelin'а, будь то ETL задача или часть CI\CD процессов, автоматизация задач эксплуатации, автотестирования.
0
+1 –1
saipr ,  
Когда я спрашивал знакомых питонистов, что им не хватает в языке многие сказали, что конструкции switch как в Си подобных языках.

Удивительно то, что python очень многое заимствует из tcl, а switch почему-то не взял.
В tcl ваш пример switch выглядит практически как у вас:


switch $a {
   1 {
      set i 2
   }
  2 {
     set i 3
  }
  default {
     set i 4
  }
}
–4
+2 –6
CaptainFlint ,  
Я на питоне пишу мало, но когда приходится, ругаюсь по таким поводам:
1. Отступы. Ну да, много копий сломано на эту тему, но для меня это недостаток.
2. Дурацкая форма тернарного оператора (value1 if condition else value 2). Сишная форма (condition? value1: value 2) моими глазами парсится проще и быстрее.
3. Невозможность присвоения внутри условия. Пару раз надо было написать код вида:
if (m = re.match('regexp1', str)):
    do_something_with(m)
elif (m = re.match('regexp2', str)):
    do_something_else_with(m)
elif …
Но поскольку так нельзя, то эта последовательная цепочка превращается в дерево вложенных if-ов.
+4
+5 –1
danfe ,   * (был изменён)
Невозможность присвоения внутри условия.
И это дико круто. За это многие паскаль по молодости не любили, а с возрастом наоборот, оценили*. :-) В петоне, кстати, из-за этого (PEP 572) целая драма случилась.
*) Помните старую историю про попытку вставить в код Linux бэкдор? Вот оно, зло присваиваний внутри условия.
+1
+4 –3
tgz ,  
Переходите на rust
+2
saluev ,  
Странно было прочесть статью про минусы Python и не увидеть упоминания GIL.
0
Enmar ,  
GIL это очень спорный момент, т.к он делает программирование безопасным (в смысле потоки синхронизируются).
0
+1 –1
Tanner ,  
PEP401 − это первоапрельская шутка, если вдруг кто не понял.

Остальные пункты − тоже несерьёзно. Не хватает проблематики. Какую именно задачу решит const или switch-case? В чём недостаток нынешних best practices? С этого надо было начинать.
+2
+3 –1
lxsmkv ,   * (был изменён)
Sтатью нужно было назвать «Отличия Python и C».

А то получилось «Слон замечательный, и я его люблю. Только, жалко, у него нет шерсти как у кота. А еще он большой и кушает много».

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

В pep-3103 описано как минимум четыре варианта синтаксиса для switch. И описаны предпочитаемые способы решения задачи, для которой в других языках часто используется switch-case.
+2
Alexey2005 ,  
Лично меня напрягает не сам язык, а его инфраструктура, в частности работа с зависимостями. Как надо поставить какой-либо компонент, так вечно вываливаются проблемы, особенно если этот компонент подразумевает наличие пачки символьных ссылок на какие-нибудь *.lib.so. Тут сразу такое шаманство начинается, что в жизни больше не захочешь с этим языком связываться.
–2
tyomitch ,  
Никто почему-то не упомянул, что Python — это опенсорс.
Кому недостаёт каких-нибудь фич, тот может делать свой собственный форк со switch и const, набирать сторонников и слать PR в мастер.
+3
danfe ,  
Слушайте, ну это несерьезный аргумент. Очевидно, что проект такого масштаба невозможно форкнуть, добавить пару (весьма при этом спорных) фич и надеяться, что твой форк внезапно станет интересен настолько, что хотя бы один популярный дистрибутив добавит его в свой репозиторий как альтернативу апстриму. Таких примеров, если они вообще есть, — единицы; я навскидку не могу вспомнить ни один.
0
tyomitch ,  
PR с фичами, тем не менее, принимают активно.
Только так фичи в языке и появляются.
0
danfe ,   * (был изменён)
С этим я не спорю, но слать PR'ы в существующий проект это совсем не то же самое, что поддерживать свой форк (если, конечно, не считать свой локальный клон репы проекта форком).

Форк — это когда ты говоришь, мол, «нам не по пути с вами, чуваки» по тем или иным причинам (как, например, OpenBSD отпочковалась от NetBSD из-за персональных разногласий, или DragonFly от FreeBSD 4.8, но тут скорее всё-таки из-за технических, хотя там была своя драма).
–1
+4 –5
MSC6502 ,  
Ключевое слово «скриптовый». Т.е. его место где-то около bat-файлов, power shell, bash и проч. Когда научится компилировать в найтивный код, тогда добро пожаловать в семью Языков Программирования, а не скриптописательства. И да, выпускаешь язык программирования скриптописательства, будь добр сразу сделать к нему нормальную IDE с отладчиком.
0
+1 –1
tyomitch ,  
Java — тоже не язык программирования, раз компилируется не в нейтив?
–4
MSC6502 ,  
Увы, да. Весь интернет держится на средстве обработки данных, прототип которого был сварганен за пару недель на коленке just ad usum internum, что называется. А потом вырвался в мир, и всё, его не остановить.
+2
+4 –2
akhalat ,  
Что просто вымораживает после си-подобных языков, так что границы блока определяют по отступам — числу пробелов, причем заменять их табуляциями не катит. На практике очень неудобно, когда копируешь код из одного шелла в другой и отступы могут сбиваться, или когда копируешь большой кусок с кучей дефов и начинает ругаться с определенного момента, хотя если разбить этот кусок на маленький и скармливать по кусочкам — ошибок нет. Почему нельзя было сохранить православные фигурные скобочки для этих целей…
+1
+2 –1
danfe ,  
Зато знаете, насколько проще читать код какого-нибудь стажера или человека с альтернативным чувством прекрасного без необходимости прогонять оный через бьютифаер, и сколько времени это экономит? ;-)
+1
+2 –1
DollaR84 ,   * (был изменён)
Это принуждает разработчиков писать удобочитаемый код. В си-подобных языках хоть и есть фигурные скобочки, но все нормальные кодостайлы требуют оформлять код отступами для удобства чтения.
+1
+3 –2
akhalat ,   * (был изменён)
Да, уверяю вас, и с сохранением отступов можно такую лапшу наварнякать, что прочитать не сможете. Главное ведь логика, стоящая за кодом. Но необходимость соблюдать отступы приводит к потере времени, когда надо бы быстро скопипастить код в шелл, а при процессе дико начинает съезжать разметка. Или когда нельзя кинуть код целиком, а приходится скармливать по частям из-за мнимых проблем с выравниванием.

оформлять код отступами для удобства чтения.

Отступы можно делать пробелами, можно табами, но питону, блин, подавай только пробелы. а текстовый редактор автоматически выраванивает табами при переносе строки, даже если предыдущая строчка была «отступлена» по пробелам. И начинается квест по автозамене… Не говоря уже о том, что конец блока не оканчивается никаким кодовым словом БЕЗ выравнивания, строка с return так и остается висеть в воздухе, и редактор так и продолжит штамповать эти новые строки с выравниванием, пока принудительно его не остановишь, что-то напечатав с самого начала строки. А питону эти пустые строки с выравниванием после ретурна опять не нравятся и начинает ругаться, ему ведь подай пустую строку без выравнивания после конца блока… Или когда надо скопировать команду из шелла выше и нечайно защепляешь ее вместе с лидирующим пробелом (от шелла) — и лезь вручную удаляй этот пробел.
вот куча таких мелочей, серьезно затормаживающих работу, и бесит
0
danfe ,  
Главное ведь логика, стоящая за кодом.
Всё так, но это вам, как опытному программисту, не составляет труда прокупить логику алгоритма даже за скверно отформатированным кодом. Начинающих же петон приучает не только (и не столько) к общепринятым правилам оформления, сколько к необходимости ясно и четко структурировать свои мысли (реализацию алгоритма); не случайно он стал так популярен для обучения программированию.
когда надо бы быстро скопипастить код в шелл, а при процессе дико начинает съезжать разметка.
У меня ничего не съезжает; возможно, у вас что-то с настройками терминала не то.
но питону, блин, подавай только пробелы.
Это неправда: второй петон допускает микс табов и пробелов (ключик -t выдаст предупреждение, -tt ошибку), третий не допускает смешивание, но допускает табы, чтобы не ломался старый код, который выровнен только табами.
+1
DollaR84 ,  
Отступы можно делать пробелами, можно табами, но питону, блин, подавай только пробелы.

Я правда использую только пробелы, и в редакторе настроена автозамена таба на пробелы, но в чьем-то коде видел вполне успешно работающие табы.
Просто надо использовать либо одно, либо другое. И нельзя их смешивать, так как пробелы и табы — это разные символы.
+1
Tremere ,  
может я неправильными редакторами пользуюсь, но в pycharm и vscode у меня не было проблем с табуляцией для кода, все легко работает как надо.

а после питона я и в c++ и в c# ставлю табуляцию в коде, в зависимости от уровня вложения, чтобы это по человечески можно было прочесть
0
robert_ayrapetyan ,  
Какая противоречивая статья, однако! +20/-20. С одной стороны, все изложенное — правда и традиционно передается из уст в уста (тот же свитч, без которого не могут сишники), с другой — все эти факты притянуты за уши (кроме производительности, которую нужно уметь приготовить в той же pandas, но справедливости ради — на любом другом языке это тоже нужно уметь).
–4
+1 –5
rgs350 ,  
Я подумал о том чего мне не хватает в Python, и что мне не нравится.
С чего вы взяли, что ваше личное мнение кого-то интересует?
0
AcckiyGerman ,  

А я бы добавил в Python встроенный тип Json с доступом к элементам как к атрибутам, через точку.
Надоело обрабатывать ответы от API как:


data["response"]["user"]["name"]

Хотелось бы:


data.response.user.name

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

0
ef_end_y ,  
а как быть с пробелами?
0
+1 –1
gnomeby ,  
Ох, мать. Ну ладно, поехали:
Константы это реально удобно, они могут существенно уменьшить число ошибок в коде.

Реально? И как же интересно? Ошибки в коде уменьшают только тесты: юнит, функциональные и интеграционные. Всё остальное это 5%. Ну ладно, ещё pylint полезный бывает.

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

Я гентушник. Меня напрягает 700-1000 пакетов в системе. Наличие в системе второго питона при таком расскаладе — незаметно.

GIL

Предположим завтра случилось чудо и кто-то написал без GIL соблюдая требования Гвидо по скорости, удобству и пр. Что изменится? Ничего. Потому что почти никому не нужны многопоточные приложения на питоне. Кому нужно быстрее и на питоне юзает: Stackless, asyncio и multiprocessing. Ещё можно numpy. Вообще сейчас уже принято не тредами а корутинами делать, ибо среднестатистический разработчик не осиливает треды безопасно.

И это всё?

А вас не напрягает например странные файлы __init__.py в папках?
А то что import в однозначно не говорит, есть файл с таким именем или объект определён в __init__.py.
Вообще что через символ подчёркивания сделано много подходов?
+1
masai ,  

Ожидал увидеть в статье список наподобие такого — https://github.com/satwikkansal/wtfpython :)

+1
Sklott ,  
Недавно столкнулся с необходимостью скомпилировать нативную библиотеку для Python для разных платформ и меня просто выморозило то, что на Linux нужен только gcc, а на Windows только MSVC.
Кроссплатформенная компиляция? Не, не слышали! Качай-ставь 4Гб MSVC чтобы скомпилировать 30 килобайтный C код.