Каковы недостатки Python? [закрыто]

В наши дни Python кажется яростью, а не незаслуженно - потому что это действительно язык, с которым почти нравится получать новую проблему для решения. Но, как однажды сказал мудрый человек (называя его мудрым человеком только потому, что я понятия не имею, кто на самом деле сказал это; не уверен, был ли он таким мудрым в все), чтобы действительно знать язык, который не только знает его синтаксис, дизайн и т. д., но и его недостатки. Ни один язык не идеален, некоторые просто лучше других.

Итак, что, на ваш взгляд, было бы объективными недостатками Python.

Примечание. Я не прошу здесь языкового сравнения (например, C # лучше, чем Python, потому что ... yadda yadda yadda) - более объективное (до определенного уровня) мнение о том, какие особенности языка плохо разработаны , то ли, может быть, некоторые из них отсутствуют в нем и так далее. Если для сравнения нужно использовать другой язык, но только для иллюстрации точки, которую трудно было бы разработать в противном случае (т. Е. Для простоты понимания)

147 голосов | спросил 4 revs, 4 users 62%
Rook
1 Jam1000000amThu, 01 Jan 1970 03:00:00 +030070 1970, 03:00:00

24 ответа


109

Я использую Python несколько регулярно, и в целом считаю это очень хорошим языком. Тем не менее, ни один язык не идеален. Вот недостатки в порядке важности для меня лично:

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

  2. Вложенные функции видны из-за того, что вы не можете изменять переменные во внешней области. Изменить: Я все еще использую Python 2 из-за поддержки библиотеки, и эта ошибка дизайна раздражает меня, но, по-видимому, она исправлена ​​в Python 3 из-за нелокальный . Не могу дождаться того, что libs я использую для портирования, чтобы этот недостаток можно было отправить в кучу истории пепла навсегда.

  3. Не хватает нескольких функций, которые могут быть полезны для библиотеки /общего кода, а ИМХО - это простота, которую вызывают нездоровые крайности. Наиболее важные из них, которые я могу представить, - это определяемые пользователем типы значений (я предполагаю, что они могут быть созданы с помощью метаклассической магии, но я никогда не пробовал) и ref function function.

  4. Это далеко от металла. Нужно писать потоковые примитивы или код ядра или что-то еще? Удачи.

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

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

ответил Let_Me_Be 13 thEurope/Moscowp30Europe/Moscow09bEurope/MoscowTue, 13 Sep 2011 18:21:08 +0400 2011, 18:21:08
66

Я ненавижу, что Python не может различать декларацию и использование переменной. Вам не нужна статическая печать, чтобы это произошло. Было бы неплохо иметь способ сказать: «Это переменная, которую я намеренно объявляю, и я намереваюсь вводить новое имя, это не опечатка.

Кроме того, я обычно использую переменные Python в стиле write-once, то есть обрабатываю переменные как неизменные и не изменяю их после их первого назначения. Благодаря таким функциям, как понимание списка, это на самом деле невероятно просто и делает поток кода более простым.

Однако я не могу подтвердить этот факт. Ничто в 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]
ответил Let_Me_Be 13 thEurope/Moscowp30Europe/Moscow09bEurope/MoscowTue, 13 Sep 2011 18:21:08 +0400 2011, 18:21:08
44

Моя основная жалоба - это многопоточность, которая во многих случаях не настолько эффективна (по сравнению с Java, C и другими) из-за глобальной блокировки интерпретатора (см. "In the the Python GIL "(PDF-ссылка) )

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

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

Также вы можете уловить многие ошибки времени выполнения, которые запускаются pylint .

ответил Let_Me_Be 13 thEurope/Moscowp30Europe/Moscow09bEurope/MoscowTue, 13 Sep 2011 18:21:08 +0400 2011, 18:21:08
28

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

ответил Let_Me_Be 13 thEurope/Moscowp30Europe/Moscow09bEurope/MoscowTue, 13 Sep 2011 18:21:08 +0400 2011, 18:21:08
27

Я думаю, что объектно-ориентированные части Python кажутся «запертыми». Вся необходимость явно передавать «я» каждому методу является признаком того, что компонент ООП не был явно запланирован , можно сказать; он также показывает иногда бородавчатые правила Python, которые были подвергнуты критике в другом ответе.

Edit:

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

Кроме того, в модели OOP от Python отсутствует какая-либо защита данных, т. е. нет частных, защищенных и открытых членов; вы можете имитировать их с помощью _ и __ перед методами, но это отвратительно. Точно так же Python не делает довольно также доступным для OOP-адреса.

ответил Let_Me_Be 13 thEurope/Moscowp30Europe/Moscow09bEurope/MoscowTue, 13 Sep 2011 18:21:08 +0400 2011, 18:21:08
19

Что мне не нравится в Python:

  1. Threading (я знаю, что он уже упоминался, но стоит упомянуть в каждом посте).
  2. Нет поддержки многолинейных анонимных функций (lambda может содержать только одно выражение).
  3. Отсутствие простой, но мощной функции чтения /класса ввода (например, cin или scanf) в C ++ и C или Scanner в Java).
  4. Все строки не являются unicode по умолчанию (но исправлены в Python 3).
ответил Let_Me_Be 13 thEurope/Moscowp30Europe/Moscow09bEurope/MoscowTue, 13 Sep 2011 18:21:08 +0400 2011, 18:21:08
18

Аргументы по умолчанию с изменяемыми типами данных.

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 = []
    ...

Особенно, когда это должно было быть по умолчанию. Это просто странное поведение, которое не соответствует тому, что вы ожидаете, и не полезно для большого количества обстоятельств.

ответил Let_Me_Be 13 thEurope/Moscowp30Europe/Moscow09bEurope/MoscowTue, 13 Sep 2011 18:21:08 +0400 2011, 18:21:08
14

Некоторые из возможностей Python, которые делают его настолько гибким, как язык разработки, также рассматриваются как серьезные недостатки тех, которые используются для статического анализа «всей программы», проводимого процессом компиляции и компоновки на таких языках, как C ++ и Java.

  • Неявное объявление локальных переменных

Локальные переменные объявляются с помощью обычного оператора присваивания. Это означает, что переменные привязки в любой другой области требуют явного аннотации, которое должно быть выбрано компилятором (глобальные и нелокальные объявления для внешних областей, нотация доступа к атрибутам для областей видимости). Это значительно уменьшает количество шаблонов, необходимых при программировании, но означает, что сторонние инструменты статического анализа (например, pyflakes) необходимы для выполнения проверок, которые обрабатываются компилятором на языках, для которых требуются явные объявления переменных.

  • Поддерживается «исправление обезьян».

Содержимое модулей, объектов класса и даже встроенного пространства имен может быть изменено во время выполнения. Это чрезвычайно мощно, что позволяет использовать многие чрезвычайно полезные методы. Однако эта гибкость означает, что Python не предлагает некоторые функции, общие для статически типизированных языков OO. Прежде всего, параметр «self» для экземпляра является явным, а не подразумеваемым (поскольку «методы» не обязательно должны быть определены внутри класса, их можно добавить позже, изменив класс, что означает, что это не особенно практично неявно передавать ссылку на экземпляр), а элементы управления доступом атрибутов не могут быть легко реализованы на основе того, является ли код «внутри» или «снаружи» класса (поскольку это различие существует только при выполнении определения класса).

  • Вдали от металла

Это также относится ко многим другим языкам высокого уровня, но Python имеет тенденцию абстрагироваться от большинства деталей оборудования. Языки системного программирования, такие как C и C ++, по-прежнему намного лучше подходят для обработки прямого доступа к аппаратным средствам (однако Python будет довольно счастливо разговаривать с ними через модули расширения CPython или, более переносимо, через библиотеку ctypes).

ответил Let_Me_Be 13 thEurope/Moscowp30Europe/Moscow09bEurope/MoscowTue, 13 Sep 2011 18:21:08 +0400 2011, 18:21:08
12
  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 ключевые слова были введены для исправления этой глупости дизайна.

ответил Let_Me_Be 13 thEurope/Moscowp30Europe/Moscow09bEurope/MoscowTue, 13 Sep 2011 18:21:08 +0400 2011, 18:21:08
11

Я нахожу комбинацию 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)

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

Я понимаю причины использования функции vs method , но я все же думаю, что это плохая идея, чтобы смешивать их так. Я был бы намного счастливее, если бы соблюдался синтаксис метода, по крайней мере для общих операций:

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() держит его сухим и все еще недвусмысленным.

И, конечно же, он имеет преимущества по сравнению с put-all-in-global-namespace . Дело не в том, что текущий способ неспособен выполнить все. Это даже довольно кратковременно (len(lst)), так как ничего не именуется! Я понимаю преимущества использования функций (поведение по умолчанию и т. Д.) Над методами, но мне все еще не нравится.

Это просто грязно. И в больших проектах беспорядок - ваш злейший враг.

ответил Let_Me_Be 13 thEurope/Moscowp30Europe/Moscow09bEurope/MoscowTue, 13 Sep 2011 18:21:08 +0400 2011, 18:21:08
8

Отсутствие homoiconicity .

Python должен был ждать 3.x, чтобы добавить ключевое слово «с». На любом гомоциконном языке его можно было бы добавить тривиально в библиотеку.

Большинство других вопросов, которые я видел в ответах, относятся к одному из трех типов:

1) Вещи, которые можно зафиксировать с помощью инструмента (например, pyflakes) 2) Детали реализации (GIL, производительность) 3) Вещи, которые могут быть исправлены с помощью стандартов кодирования (т. Е. Людей, желающих не присутствовать)

# 2 не проблема с языком, IMO # 1 и # 3 не являются серьезными проблемами.

ответил Let_Me_Be 13 thEurope/Moscowp30Europe/Moscow09bEurope/MoscowTue, 13 Sep 2011 18:21:08 +0400 2011, 18:21:08
7

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

  • Нет реальных анонимных функций. Lambda может использоваться для функций с одним оператором, а оператор with может использоваться для многих вещей, где вы бы использовали блок кода в Ruby. Но в некоторых ситуациях это делает вещи немного более неуклюжими, чем они должны были бы быть. (Далека от такой неуклюжий, как в Java, но все же ...)

  • Некоторая путаница в отношении между модулями и файлами. Запуск «python foo.py» из командной строки отличается от «import foo». Относительный импорт в Python 2.x также может вызвать проблемы. Тем не менее, модули Python намного лучше, чем соответствующие функции C, C ++ и Ruby.

  • Явный self. Хотя я понимаю некоторые причины этого, и хотя я использую Python ежедневно, я склонен ошибаться, забыв об этом. Другая проблема заключается в том, что становится немного утомительным сделать класс из модуля. Явное «я» связано с ограниченным охватом, о котором другие жаловались. Наименьший объем в Python - это область функций. Если вы сохраняете свои функции небольшими, как и следовало ожидать, это не проблема сама по себе, и IMO часто дает более чистый код.

  • Некоторые глобальные функции, такие как len, которые вы ожидаете быть методом (который он фактически за кулисами).

  • Значительный отступ. Не сама идея, и я думаю, что это здорово, но поскольку это единственное, что удерживает так много людей от попыток Python, возможно, Python будет лучше с некоторыми (необязательными) символами начала и конца. Игнорируя этих людей, я мог полностью жить с принудительным размером для отступов.

  • Это не встроенный язык веб-браузеров, а не JavaScript.

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

ответил Let_Me_Be 13 thEurope/Moscowp30Europe/Moscow09bEurope/MoscowTue, 13 Sep 2011 18:21:08 +0400 2011, 18:21:08
5

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

Вероятно, в середине 2012 года это будет меньше недостатком.

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

Зрелость в одном главном смысле означает, что команда может использовать эту технологию и быть очень быстро up & без скрытых рисков (включая проблемы с совместимостью). Сторонние пакеты python и многие приложения сегодня не работают в версии 3.2 для большинства пакетов. Это создает больше работы по интеграции, тестированию, переопределению самой технологии, а не решению проблемы под рукой == менее зрелая технология.

Обновление за июнь 2013 года: Python 3 все еще имеет проблемы со зрелостью. Каждый так часто член команды упоминает о пакете, который требуется, а затем говорит «за исключением того, что он предназначен только для версии 2.6» (в некоторых из этих случаев я применил обходное решение через сокет localhost для использования пакета с 2.6-версией с 2.6, а остальная часть наши инструменты остаются с 3.2). Не даже MoinMoin, wiki-файл pure-python, написан на Python 3.

ответил Let_Me_Be 13 thEurope/Moscowp30Europe/Moscow09bEurope/MoscowTue, 13 Sep 2011 18:21:08 +0400 2011, 18:21:08
4

Область Python сильно повреждена, что делает объектно-ориентированное программирование на Python очень неудобным.

ответил Let_Me_Be 13 thEurope/Moscowp30Europe/Moscow09bEurope/MoscowTue, 13 Sep 2011 18:21:08 +0400 2011, 18:21:08
4

Мои проблемы с Python:

  • Болтовое ООП (см. ответ @ mipadi для разработки этого)
  • Сломанная реализация lambdas
  • Сфера действия
  • Нет постоянных коллекций в стандартной библиотеке
  • Плохая совместимость с встроенными DSL
ответил Let_Me_Be 13 thEurope/Moscowp30Europe/Moscow09bEurope/MoscowTue, 13 Sep 2011 18:21:08 +0400 2011, 18:21:08
4

Модификаторы доступа в Python не могут быть реализованы - затрудняет запись хорошо структурированного, модульного кода.

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

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

ответил Let_Me_Be 13 thEurope/Moscowp30Europe/Moscow09bEurope/MoscowTue, 13 Sep 2011 18:21:08 +0400 2011, 18:21:08
3
  1. Производительность не очень хорошая, но улучшается с помощью pypy,
  2. GIL предотвращает использование потоковой передачи для ускорения кода (хотя это, как правило, преждевременная оптимизация),
  3. Это полезно только для программирования приложений,

Но у него есть некоторые замечательные возможности:

  1. Это идеально подходит для RAD,
  2. Легко взаимодействовать с C (и для C, чтобы внедрить интерпретатор python),
  3. Это очень читаемо,
  4. Легко учиться,
  5. Это хорошо документировано,
  6. Батареи действительно включены, стандартная библиотека огромна, а pypi содержит модули практически для всего,
  7. У этого есть здоровое сообщество.
ответил Let_Me_Be 13 thEurope/Moscowp30Europe/Moscow09bEurope/MoscowTue, 13 Sep 2011 18:21:08 +0400 2011, 18:21:08
3

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

ответил Let_Me_Be 13 thEurope/Moscowp30Europe/Moscow09bEurope/MoscowTue, 13 Sep 2011 18:21:08 +0400 2011, 18:21:08
3

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

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

ответил Let_Me_Be 13 thEurope/Moscowp30Europe/Moscow09bEurope/MoscowTue, 13 Sep 2011 18:21:08 +0400 2011, 18:21:08
3
  • довольно куча очень распространенных сторонних библиотек и программного обеспечения, которые широко используются, не совсем питоничны. Несколько примеров: soaplib, openerp, reportlab. Критика не входит в сферу действия, она там, она широко используется, но это путает питонскую культуру (это вредит девизу, который гласит: «Должен быть один - и желательно только один - простой способ сделать это»). Исключение составляют известные питонические успехи (например, django или trac).
  • потенциально неограниченная глубина абстракции экземпляра, класса, метакласса концептуально красива и уникальна. Но чтобы справиться с этим, вы должны глубоко понимать интерпретатора (в каком порядке интерпретируется код python и т. Д.). Он не широко известен и используется (или используется правильно), в то время как аналогичная черная магия, такая как C # generics, концептуально более запутанная (IMHO), кажется более широко известной и используется пропорционально.
  • Чтобы получить хорошее представление о модели памяти и потоковой передачи, вы должны быть достаточно опытны с python, потому что нет всеобъемлющей спецификации. Вы просто знаете, что работает, может быть, потому, что вы читали источники интерпретатора или опытные причуды и выяснили, как их исправить. Например, есть только сильные или слабые ссылки, а не мягкие и фантомные ссылки на java. Java имеет поток для сбора мусора, в то время как нет официального ответа о том, когда сборка мусора происходит в python; вы можете просто заметить, что сбор мусора не происходит, если не выполняется код python, и заключить, что это, вероятно, происходит иногда при попытке выделить память. Может быть сложно, когда вы не знаете, почему заблокированный ресурс не был выпущен (мой опыт об этом был mod_python в freeswitch).

Во всяком случае, python - это мой основной язык в течение 4 лет. Будучи фанатами, элитаристы или мономаньяки не являются частью культуры питона.

ответил Let_Me_Be 13 thEurope/Moscowp30Europe/Moscow09bEurope/MoscowTue, 13 Sep 2011 18:21:08 +0400 2011, 18:21:08
2
  • Странный ООП:
    • len(s) через __len__(self) и другие "специальные методы"
    • дополнительные специальные методы, которые могут быть получены из других специальных методов (__add__ и __iadd__ для + и +=) литий>
    • self как первый параметр метода
    • вы можете забыть вызвать конструктор базового класса
    • нет модификаторов доступа (закрытых, защищенных ...)
  • нет константных определений
  • нет неизменяемости для настраиваемых типов
  • GIL
  • низкая производительность, что приводит к сочетанию Python и C и проблем со сборками (ищет C libs, зависимости от платформы).
  • плохая документация, особенно в сторонних библиотеках
  • несовместимость между Python 2.x и 3.x
  • инструменты анализа слабого кода (по сравнению с тем, что предлагается для статически типизированных языков, таких как Java или C #)
ответил Let_Me_Be 13 thEurope/Moscowp30Europe/Moscow09bEurope/MoscowTue, 13 Sep 2011 18:21:08 +0400 2011, 18:21:08
0

«Неизменность» - это не совсем так. Номера AFAIK, кортежи и строки неизменяемы, все остальное (т. Е. Объекты) изменчиво. Сравните это с функциональными языками, такими как Erlang или Haskell, где все неизменно (по умолчанию, по крайней мере).

Тем не менее, Immutability действительно действительно сияет с параллелизмом *, что также не является сильной стороной Python, поэтому, по крайней мере, это связано с этим.

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

ответил Let_Me_Be 13 thEurope/Moscowp30Europe/Moscow09bEurope/MoscowTue, 13 Sep 2011 18:21:08 +0400 2011, 18:21:08
0

Мне бы хотелось иметь явно параллельные конструкции. Чаще всего, когда я пишу понимание списка, например

[ f(x) for x in lots_of_sx ]

Мне не нужен порядок, в котором будут обрабатываться элементы. Иногда мне даже неважно, в каком порядке они возвращаются.

Даже если CPython не может сделать это хорошо, когда мой f является чистым Python, такое поведение может быть определено для других применений.

ответил Let_Me_Be 13 thEurope/Moscowp30Europe/Moscow09bEurope/MoscowTue, 13 Sep 2011 18:21:08 +0400 2011, 18:21:08
0

У Python отсутствует оптимизация «хвостов», в основном для философских причин . Это означает, что хвостохранилище на больших структурах может стоить O (n) памяти (из-за ненужного стека, который сохраняется), и вам потребуется переписать рекурсию как цикл для получения O (1) памяти.

ответил Let_Me_Be 13 thEurope/Moscowp30Europe/Moscow09bEurope/MoscowTue, 13 Sep 2011 18:21:08 +0400 2011, 18:21:08

Похожие вопросы

Популярные теги

security × 330linux × 316macos × 2827 × 268performance × 244command-line × 241sql-server × 235joomla-3.x × 222java × 189c++ × 186windows × 180cisco × 168bash × 158c# × 142gmail × 139arduino-uno × 139javascript × 134ssh × 133seo × 132mysql × 132