Які недоліки Python? [зачинено]

Сьогодні Python здається всім гнівом, і це не незаслужено - адже це справді мова, якою майже не подобається отримувати нову проблему. Але, як казав колись мудрець (називаючи його мудрою людиною лише тому, що я не маю уявлення про те, хто це насправді сказав; не впевнений, чи був він таким мудрим взагалі), щоб справді знати мову, вона не лише знає її синтаксис, дизайн тощо, переваги, але також і його недоліки. Жодна мова не ідеальна, деякі просто кращі за інші.

Отже, які, на вашу думку, об’єктивні недоліки Python.

Примітка: я не прошу тут порівняння мови (тобто C # кращий, ніж Python, тому що ... yadda yadda yadda) - більше об'єктивна (на деякий рівень) думка про те, які мовні особливості погано розроблені, чи є, що можливо дещо вам не вистачає в ньому тощо. Якщо потрібно використовувати іншу мову в якості порівняння, але лише для ілюстрації пункту, який важко було б розробити інакше (тобто для зручності розуміння)

Я використовую Python кілька регулярно, і в цілому я вважаю це дуже хорошою мовою. Тим не менш, жодна мова не є досконалою. Ось недоліки за важливістю для мене особисто:

1. Це повільно. Я маю на увазі дійсно, дуже повільно. Багато разів це не має значення, але це, безумовно, означає, що вам потрібна інша мова для цих критично важливих бітів.

2. Вкладені функції начебто всмоктуються тим, що ви не можете змінювати змінні у зовнішній області. Редагувати: Я все ще використовую Python 2 завдяки підтримці бібліотеки, і цей недолік дизайну дратує хек у мене, але, мабуть, він виправлений в Python 3 через нелокальне твердження. Не можу чекати, коли мочки, які я використовую, перенесуться, щоб цей недолік можна назавжди відправити до попелу.

3. Не вистачає кількох функцій, які можуть бути корисними для бібліотечного / загального коду, а IMHO - це простота, яка сприймається до нездорових крайнощів. Найбільш важливі з них, які я можу придумати, - це визначені користувачем типи значень (я здогадуюсь, що їх можна створити за допомогою магії метакласу, але я ніколи не пробував) та параметр ref ref.

4. Це далеко не метал. Потрібно написати примітивні нитки або код ядра чи щось таке? Удачі.

5. Хоча я не заперечую проти відсутності можливості ловити семантичні помилки наперед, як компроміс за динамізм, який пропонує Python, я б хотів, щоб існував спосіб ловити синтаксичні помилки та дурні речі, такі як помилка імен змінних без фактичного запуску коду.

6. Документація не настільки хороша, як мови, як PHP та Java, які мають міцну корпоративну підтримку.

Я ненавиджу, що Python не може розрізняти декларацію та використання змінної. Вам не потрібно статичного введення, щоб це сталося. Було б просто добре сказати "це змінна, яку я свідомо декларую, і я маю намір ввести нове ім'я, це не помилка друку".

Крім того, я зазвичай використовую змінні Python у стилі запису один раз, тобто я вважаю, що змінні є незмінними та не змінюють їх після їх першого призначення. Завдяки таким функціям, як розуміння списків, це насправді неймовірно просто і робить потік коду більш легким у дотриманні.

Однак я не можу зафіксувати цей факт. Ніщо в Python не заважає мені формувати перезапис або повторне використання змінних.

Підсумовуючи, я хотів би мати дві ключові слова в мові: varі let. Якщо я пишу в змінну, не оголошену жодною з них, Python повинен викликати помилку. Крім того, letоголошує змінні як лише для читання, тоді як varзмінні є "нормальними".

Розглянемо цей приклад:

x = 42    # Error: Variable `x` undeclared

var x = 1 # OK: Declares `x` and assigns a value.
x = 42    # OK: `x` is declared and mutable.

var x = 2 # Error: Redeclaration of existing variable `x`

let y     # Error: Declaration of read-only variable `y` without value
let y = 5 # OK: Declares `y` as read-only and assigns a value.

y = 23    # Error: Variable `y` is read-only

Зауважте, що типи все ще є неявними (але letзмінні для всіх намірів і цілей вводяться статично, оскільки їх неможливо відновити до нового значення, тоді як varзмінні все ще можуть бути динамічно набрані).

Нарешті, всі аргументи методу повинні бути автоматично let, тобто вони повинні бути лише для читання. Взагалі немає вагомих причин змінювати параметр, за винятком наступної ідіоми:

def foo(bar = None):
    if bar == None: bar = [1, 2, 3]

Це могло б замінити дещо іншу ідіому:

def foo(bar = None):
    let mybar = bar or [1, 2, 3]

Моя основна скарга - це нарізання різьби, яке за багатьох обставин не є таким виконавським (порівняно з Java, C та іншими) через глобальне блокування інтерпретатора (див. Розмову "Всередині Python GIL" (PDF-посилання) )

Однак є багатопроцесорний інтерфейс, який дуже простий у використанні, однак це буде важче у використанні пам'яті для однакової кількості процесів порівняно з потоками, або складно, якщо у вас багато спільних даних. Перевага полягає в тому, що коли у вас є програма, що працює над декількома процесами, вона може масштабуватись на декількох машинах, щось з потоковою програмою не може зробити.

Я дійсно не згоден з критикою документації, я вважаю, що вона відмінна і краща, ніж більшість, якщо не всі основні мови там.

Крім того, ви можете зловити багато помилок під час виконання, коли працює пілінт .

Можливо , відсутність статичної типізації, яка може запровадити певні класи помилок виконання , не варто додаткової гнучкості, яку забезпечує типінг качки.

Я думаю, що об'єктно-орієнтовані частини Python відчувають себе наче «застебнутими». Вся потреба в явній передачі "Я" кожному методу є симптомом того, що його компонент OOP не був чітко спланований , можна сказати; це також показує іноді бородавкові правила визначення розміру Python, які були піддані критиці в іншій відповіді.

Редагувати:

Коли я кажу, що об'єктно-орієнтовані частини Python відчувають себе «застебнутими», я маю на увазі, що часом сторона ООП відчуває себе досить непослідовною. Візьмімо, наприклад, Ruby: у Ruby все є об'єктом, і ви викликаєте метод, використовуючи знайомий obj.methodсинтаксис (за винятком, перевантажених операторів, звичайно); у Python теж все є об'єктом, але деякі методи ви називаєте функцією; тобто ви перевантажуєте, __len__щоб повернути довжину, але називаєте її, використовуючи len(obj)замість більш звичного (і послідовного) obj.lengthзагального для інших мов. Я знаю, що в цьому дизайнерському рішенні є причини, але вони мені не подобаються.

Крім того, у моделі OOP Python не вистачає будь-якого типу захисту даних, тобто немає приватних, захищених та публічних членів; ви можете імітувати їх, використовуючи _і __перед методами, але це щось некрасиво. Точно так же, Python НЕ зовсім отримати повідомлення обходячи аспект об'єктно - орієнтованого права, або.

Що мені не подобається в Python:

1. Тематика (я знаю, що її вже згадувалося, але варто згадати в кожному дописі).
2. Немає підтримки багаторядкових анонімних функцій ( lambdaможе містити лише один вираз).
3. Відсутність простий , але потужний вхід читання функції / класу (як cinі scanfв C ++ і C або Scannerв Java).
4. Усі рядки за замовчуванням не є унікодом (але зафіксовані в Python 3).

Аргументи за замовчуванням із змінними типами даних.

def foo(a, L = []):
    L.append(a)
    print L

>>> foo(1)
[1]
>>> foo(2)
[1, 2]

Зазвичай це результат деяких тонких помилок. Я думаю, що було б краще, якщо він створив новий об'єкт списку, коли потрібен аргумент за замовчуванням (а не створення одного об'єкта, який потрібно використовувати для кожного виклику функції).

Редагувати: Це не величезна проблема, але коли щось потрібно згадати в документах, це зазвичай означає, що це проблема. Це не потрібно.

def foo(a, L = None):
    if L is None:
        L = []
    ...

Особливо, коли це мало бути за замовчуванням. Це просто дивна поведінка, яка не відповідає тому, що ви очікували, і не корисна для великої кількості обставин.

Деякі особливості Python, які роблять його настільки гнучким як мова для розробки, також розглядаються як основні недоліки тих, які використовуються для статичного аналізу "цілої програми", що проводиться процесом компіляції та з'єднання на таких мовах, як C ++ та Java.

• Неявне оголошення локальних змінних

Локальні змінні оголошуються за допомогою звичайного оператора призначення. Це означає, що змінні прив’язки в будь-якій іншій області вимагають, щоб компілятор вибирав явні анотації (глобальні та нелокальні декларації для зовнішніх областей, позначення доступу до атрибутів, наприклад, області застосування). Це значно зменшує кількість котлоагрегату, необхідного при програмуванні, але означає, що необхідні інструменти статичного аналізу сторонніх сторін (такі як піфляки) для здійснення перевірок, які обробляються компілятором мовами, які вимагають явних оголошень змінних.

• "Мавпа патч" підтримується

Вміст модулів, об’єктів класу і навіть вбудований простір імен можна змінювати під час виконання. Це надзвичайно потужно, що дозволяє багато надзвичайно корисних методик. Однак ця гнучкість означає, що Python не пропонує деяких функцій, спільних для мов OO зі статичним набором. Найголовніше, що параметр "self" для примірників методів є явним, а не неявним (оскільки "методи" не повинні визначатися всередині класу, вони можуть бути додані пізніше, модифікуючи клас, тобто це не особливо практично) передавати посилання на екземпляр неявно) та керувати доступом до атрибутів не можна легко застосувати на основі того, чи є код "всередині" чи "зовні" класу (оскільки це відмінність існує лише під час виконання визначення класу).

• Далеко від металу

Це також стосується багатьох інших мов високого рівня, але Python прагне абстрагувати більшість апаратних деталей. Мови програмування систем, такі як C та C ++, все ще набагато краще підходять для прямого доступу до апаратного забезпечення (однак, Python цілком із задоволенням розмовлятиме з ними або через модулі розширення CPython, або, ще більш портативно, через ctypesбібліотеку).

1. Використання відступів для блоків коду замість {} / begin-end, як би там не було.
2. Кожна нова сучасна мова має належне лексичне визначення, але не Python (див. Нижче).
3. Хаотичні документи (порівняйте з документацією Perl5, яка чудово).
4. Куртка з протокою (існує лише один спосіб зробити це).

Приклад розбитого масштабу; стенограма з сеансу перекладача:

>>> x=0
>>> def f():
...     x+=3
...     print x
... 
>>> f()
Traceback (most recent call last):
  File "", line 1, in ?
  File "", line 2, in f
UnboundLocalError: local variable 'x' referenced before assignment

globalі nonlocalключові слова були введені для виправлення цієї дизайнерської дурості

Я вважаю поєднання python об'єктно-орієнтованого this.method()та процедурно-функціонального method(this)синтаксису дуже неспокійним:

x = [0, 1, 2, 3, 4]
x.count(1)
len(x)
any(x)
x.reverse()
reversed(x)
x.sort()
sorted(x)

Це особливо погано, оскільки велика кількість функцій (а не методів) просто скидаються в глобальний простір імен : методи, що стосуються списків, рядків, чисел, конструкторів, метапрограмування, всі об'єднані в один великий алфавітно-відсортований список.

Принаймні, такі функціональні мови, як F #, мають усі функції, правильно розподілені в модулях:

List.map(x)
List.reversed(x)
List.any(x)

Отже, вони не всі разом. Крім того, цей стандарт дотримується у всій бібліотеці, так що принаймні він відповідає.

Я розумію причини виконання функції в порівнянні з методом , але я все ще думаю, що це погана ідея їх змішувати так. Я був би набагато щасливішим, якби дотримувався синтаксис методу, принаймні для звичайних операцій:

x.count(1)
x.len()
x.any()
x.reverse()
x.reversed()
x.sort()
x.sorted()

Незалежно від того, мутують вони методи чи ні, використання їх як методів на об'єкті має ряд переваг:

• Єдине місце для пошуку "загальних" операцій над типом даних: інші бібліотеки / тощо. можуть бути інші химерні речі, які вони можуть зробити для типів даних, але операції "за замовчуванням" - всі в методах об'єкта.
• Не потрібно постійно повторювати Moduleдзвінки під час дзвінка Module.method(x). Беручи приклад функціонального списку вище, чому я повинен постійно говорити List? Він повинен знати, що це є, Listі я не хочу викликати Navigation.map()функцію на ньому! Використання x.map()синтаксису зберігає його СУХО та однозначно.

І звичайно, він має переваги перед способом цього " все-у-глобальному"-просторі імен . Справа не в тому, що нинішній спосіб не в змозі зробити справи. Це навіть досить коротко ( len(lst)), оскільки нічого не розділено на імена! Я розумію переваги використання функцій (поведінка за замовчуванням тощо) перед методами, але все одно мені це не подобається.

Це просто безладно. А у великих проектах безладдя - ваш найгірший ворог.

Відсутність гомонічності .

Python довелося чекати 3.x, щоб додати ключове слово "з". Будь-якою гомоніконімічною мовою це можна було б тривіально додати до бібліотеки.

Більшість інших питань, які я бачив у відповідях, мають один із 3 типів:

1) Речі, які можна виправити за допомогою інструментарію (наприклад, піфлейки) 2) Деталі впровадження (GIL, продуктивність) 3) Речі, які можна виправити за допомогою стандартів кодування (тобто функції, за які люди бажають, щоб їх не було)

№2 не є проблемою з мовою, ІМО №1 та №3 не є серйозними проблемами.

Python - це моя улюблена мова, оскільки вона дуже виразна, але все одно не дає вам робити занадто багато помилок. У мене ще є кілька речей, які мене дратують:

• Немає справжніх анонімних функцій. Лямбда може використовуватися для функцій з одним оператором, а withоператор може використовуватися для багатьох речей, де ви використовували б блок коду в Ruby. Але в деяких ситуаціях це робить дещо незграбнішими, ніж вони мали б бути. (Далеко не такий незграбний, як це було б на Яві, але все ж ...)

• Певна плутанина у відношенні між модулями та файлами. Запуск "python foo.py" з командного рядка відрізняється від "import foo". Відносний імпорт в Python 2.x також може спричинити проблеми. Тим не менш, модулі Python набагато краще, ніж відповідні функції C, C ++ і Ruby.

• Явне self. Незважаючи на те, що я розумію деякі причини цього, і хоча я використовую Python щодня, я, як правило, помиляюсь про це. Інша проблема з цим полягає в тому, що робити клас з модуля стає трохи нудно. Явне самоврядування пов'язане з обмеженою сферою застосування, на яку скаржилися інші. Найменша сфера застосування в Python - це область функцій. Якщо ви зберігаєте свої функції невеликими, як слід, це не є проблемою само по собі, і IMO часто надає більш чистий код.

• Деякі глобальні функції, такі як, наприклад len, те, що ви можете очікувати як метод (який він насправді знаходиться поза кадром).

• Значне відступ. Не сама ідея, яка, на мою думку, є чудовою, але оскільки це єдина річ, яка заважає багатьом людям спробувати Python, можливо, Python буде краще з деякими (необов'язковими) символами початку / кінця. Ігноруючи цих людей, я міг би повністю жити з примусовим розміром для відступу теж.

• Що це не вбудована мова веб-браузерів, а не JavaScript.

З цих скарг я лише найперший, який мені досить хвилює, що я думаю, що його слід додати до мови. Інші досить незначні, за винятком останнього, що було б чудово, якби це сталося!

Python не повністю зрілий: мова python 3.2 в цей час має проблеми з сумісністю з більшістю розповсюджених в даний час пакетів (зазвичай вони сумісні з python 2.5). Це великий недолік, який в даний час вимагає більше зусиль для розробки (знайдіть необхідний пакет; перевірте сумісність; зважте, вибираючи недобрий пакет, який може бути більш сумісним; візьміть найкращу версію, оновіть її до 3.2, що може зайняти кілька днів; потім починайте робити щось корисне).

Ймовірно, в середині 2012 року це буде меншим недоліком.

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

Зрілість в одному головному сенсі означає, що команда може використовувати цю технологію і дуже швидко працювати і працювати без прихованих ризиків (включаючи проблеми сумісності). Пакети пітонів третьої сторони та багато додатків не працюють під 3.2 для більшості пакетів сьогодні. Це створює більше роботи з інтеграції, тестування, повторного вдосконалення самої технології замість вирішення проблеми під рукою == менш зріла технологія.

Оновлення за червень 2013 року: у Python 3 все ще є проблеми зрілості. Кожен настільки часто член команди згадує необхідний пакет, після чого скаже "за винятком лише 2.6" (у деяких з цих випадків я реалізував рішення через localhost socket, щоб використовувати пакет, що містить лише 2.6 з 2.6, а решта наші інструменти залишаються з 3.2). Навіть MoinMoin, вікі з чистого пітона, написаний у Python 3.

Область застосування Python дуже порушена, що робить об’єктно-орієнтоване програмування в Python дуже незручним.

Мої схвалення про Python:

• OOP з підключеним процесором (див. Відповідь @ mipadi для розробки цього питання)
• Порушена реалізація лямбда
• Сфера застосування
• У стандартній бібліотеці немає постійних колекцій
• Погана здатність до вбудованих DSL

Модифікатори доступу в Python не підлягають застосуванню - ускладнює написання добре структурованого модульованого коду.

Я вважаю, що це частина розбитого обліку @ Мейсона - велика проблема загалом з цією мовою. Для коду, який повинен бути читабельним, здається, досить складно зрозуміти, що може і що має бути в області застосування та яке значення буде у будь-який момент часу - я зараз думаю про перехід від мови Python через ці недоліки .

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

1. Продуктивність не є хорошою, але покращується з pypy,
2. GIL запобігає використанню нитки для прискорення коду (хоча це, як правило, передчасна оптимізація),
3. Це корисно лише для програмування додатків,

Але він має деякі чудові функції викупу:

1. Він ідеально підходить для RAD,
2. Інтерфейс з C (і для C вбудовувати інтерпретатора python) легко,
3. Це дуже легко читається,
4. Це легко навчитися,
5. Це добре задокументовано,
6. Батареї дійсно включені, стандартна бібліотека величезна, а піпі містить модулі практично для всього,
7. У ньому є здорове співтовариство.

Я віддаю перевагу python, і перший недолік, який мені спадає на думку, це коли коментувати заяву, як if myTest():тоді, ви повинні змінити відступ у всьому виконаному блоці, який би вам не доводилося робити з C або Java. Насправді в python замість того, щоб коментувати пункт-if, замість цього я почав коментувати це так: `if True: #myTest (), тому мені також не доведеться змінювати наступний блок коду. Оскільки Java і C не покладаються на відступи, це полегшує коментування тверджень за допомогою C та Java.

Багаторазова відправка не добре поєднується зі встановленою системою одноразового типу та не є дуже ефективною.

Динамічне завантаження - це велика проблема в паралельних файлових системах, де семантика, схожа на POSIX, призводить до катастрофічних уповільнень для операцій з інтенсивними метаданими. У мене є колеги, які спалили чверть мільйона основних годин, просто отримуючи Python (з numpy, mpi4py, petsc4py та іншими модулями розширення), завантаженими на 65 кер. (Моделювання дало значні нові наукові результати, тому воно того варте, але це проблема, коли спалюється більше, ніж барель нафти, щоб завантажувати Python один раз.) Неможливість статичного зв’язку змусила нас піти на великі суперечки, щоб отримати розумні рази завантаження в масштабі, включаючи виправлення libc-rtld для забезпечення dlopenколективного доступу до файлової системи.

• чимало бібліотек та програмного забезпечення, які широко використовуються сторонніми компаніями, які широко використовуються, є не пітонічними. Кілька прикладів: soaplib, openerp, reportlab. Критика поза сферою, вона існує, вона широко використовується, але це робить культуру пітона заплутаною (це шкодить девізу, який говорить: "Має бути один - і бажано лише один - очевидний спосіб це зробити"). Відомі пітонічні успіхи (наприклад, джанго чи трак), здаються, є винятком.
• потенційно необмежена глибина абстрагування екземпляра, класу, метакласу є концептуально красивою та унікальною. Але для того, щоб засвоїти його, ви повинні глибоко знати інтерпретатора (в якому порядку інтерпретується код python тощо). Він не широко відомий і використовується (або використовується правильно), в той час як подібні чорні магії, такі як C # generics, тобто концептуально більш згорнуті (IMHO), здаються більш широко відомими та використовуються пропорційно.
• щоб добре зрозуміти модель пам’яті та нарізки, вам доведеться бути досить досвідченим з python, тому що немає всеосяжної характеристики. Ви просто знаєте, що працює, можливо, тому, що ви прочитали джерела перекладача або досвідчені химерності та дізналися, як їх виправити. Наприклад, є лише сильні або слабкі посилання, а не м'які та фантомні відбиття Java. У Java є нитка для збору сміття, поки немає офіційної відповіді про те, коли збирання сміття відбувається в python; ви можете просто спостерігати, що збирання сміття не відбувається, якщо не виконується код python, і зробити висновок, що це, мабуть, трапляється іноді при спробі виділення пам'яті. Може бути складним, коли ви не знаєте, чому заблокований ресурс не був випущений (мій досвід про це був mod_python в freeswitch).

Так чи інакше, Python - моя головна мова вже 4 роки. Бути фанбоями, елітистами або одноманітниками не є частиною культури пітона.

• Дивний OOP:
  • len(s)за допомогою __len__(self)та інших "спеціальних методів"
  • додаткові спеціальні методи, які можна отримати від інших спеціальних методів ( __add__і __iadd__для +та +=)
  • self як перший параметр методу
  • ви можете забути викликати конструктор базового класу
  • відсутні модифікатори доступу (приватні, захищені ...)
• немає постійних визначень
• відсутність незмінності для користувацьких типів
• GIL
• низька продуктивність, що призводить до поєднання Python та C та проблем із збірками (шукаючи C libs, залежність від платформи ...)
• погана документація, особливо в сторонніх лайках
• несумісність між Python 2.x та 3.x
• погані інструменти аналізу коду (порівняно з тими, які пропонуються для мов, які набираються статично, таких як Java або C #)

"Незмінюваність" - це не зовсім сильна сторона. Номери, кортежі та рядки AFAIK незмінні, все інше (тобто об'єкти) змінюється. Порівняйте це з функціональними мовами, такими як Erlang або Haskell, де все незмінне (як мінімум).

Однак Immutability насправді світить паралельністю *, що також не є сильною стороною Python, так що, принаймні, це є наслідком.

(* = Для ниткопідбирачів: я маю на увазі сумісність, яка принаймні частково паралельна. Я думаю, що в Python нормально з однонитковою одночасністю, в якій незмінність не так важлива. (Так, любителі FP, я знаю, що незмінність - це чудово навіть без одночасності.))

Я хотів би мати явно паралельні конструкції. Найчастіше, коли я пишу таке розуміння списку

[ f(x) for x in lots_of_sx ]

Мене не хвилює порядок обробки елементів. Іноді мені навіть байдуже, в якому порядку вони повертаються.

Навіть якщо CPython не може зробити це добре, коли мій f чистий Python, така поведінка може бути визначена для інших застосувань.

Python не має оптимізації для виклику хвостів, здебільшого з філософських причин . Це означає, що повторення хвоста на великих структурах може коштувати O (n) пам’яті (через непотрібний стек, який зберігається) і вимагатиме від вас переписати рекурсію як цикл для отримання O (1) пам’яті.