перечислите недостатки Python

Чего мелочиться, давайте уж сразу Lisp'а.

Отступы - это ТруЪ. Вам не приходилось студенческий быдлокод без форматированя отлаживать?

1) [субъективно] не удобный *лично мне* синтаксис.

2) ограничение лямбды по размеру.

3) отсутвие switch/case (вполне обходимое, но не приятное)

> Чего мелочиться, давайте уж сразу Lisp'а.

1) перегруженность мусором common lisp'a. не стоит это отрицать, она имеет место быть. вполне обходима не использованием не нужного функционала =)

Python 2.5.1 (r251, Sep 29 2007, 13:32:49) [GCC 4.2.1] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> len("абвгд") 10

Python 3.0a2 (r30a2:59382, Jan 23 2008, 13:30:56) [GCC 4.2.2] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> len("абвгд") 5

Python 2.5.1 (r251, Sep 29 2007, 13:32:49) 
[GCC 4.2.1] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> len("абвгд")
10

Python 3.0a2 (r30a2:59382, Jan 23 2008, 13:30:56) 
[GCC 4.2.2] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> len("абвгд")
5

> отсутвие switch/case (вполне обходимое, но не приятное)

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

http://docs.python.org/tut/node5.html#SECTION005130000000000000000

я бы сказал, что это очень субъективно. мне ни в перле, ни в питоне, отсутвие switch/case жутко не нравится. но ключевое слово здесь - *мне* =)

>Вам не приходилось студенческий быдлокод без форматированя отлаживать?

code formatter? А вот для Python такой штуки нет и быть не может.

> code formatter? А вот для Python такой штуки нет и быть не может.

Не уверен в функциях данного поделия, но подозреваю, что в случае с Python оно не нужно по определению.

>Отступы - это ТруЪ. Вам не приходилось студенческий быдлокод без форматированя отлаживать?

безусловно, я сразу расставлял отступы. но вот мое видение правил форматирования имеет свои отклонения

То, что тотальная динамическая природа языка - это зло, всем понятно? Тогда по мелочам: отсуствие public/private, дурацкая манера создавать поля при присваивании. Еще сильно хотелось бы pattern matching.

отсутсвие типизации, отсутствие сопоставления с образцом

> То, что тотальная динамическая природа языка - это зло, всем понятно?

Нет :)

>>code formatter?

Можно ссылку? Мне вот попадались тоько под винду =(

indent например для C.

> То, что тотальная динамическая природа языка - это зло, всем понятно?

Мне не понятно..

> отсутсвие типизации, отсутствие сопоставления с образцом

http://en.wikipedia.org/wiki/Dynamic_type

>> отсутсвие типизации, отсутствие сопоставления с образцом

> http://en.wikipedia.org/wiki/Dynamic_type

Имелась в виду, естественно, статическая типихация. И как всё же насчет pattern matching? :)

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

Мне не нравится отсутствие статической типизации и компиляции - если бы они были, многие ошибки определялись бы ещё при компиляции. И ещё скорость работы. А так вполне ничего.

> И как всё же насчет pattern matching? :)

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

> Имелась в виду, естественно, статическая типихация.

в лиспе, допустим, её тоже нету, он это же не мешает лиспу =) посему я бы не сказал, что динамическая типизая - недостаток. иногда это даже преимущество. =)

> отсутствие сопоставления с образцом

поясните.

> И ещё скорость работы.

по сравнению с чем? =)

> Мне не нравится отсутствие статической типизации и компиляции - если бы они были, многие ошибки определялись бы ещё при компиляции. И ещё скорость работы. А так вполне ничего.

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

anonymous, жжошь)))

> бы не сказал, что динамическая типизая - недостаток. иногда это даже преимущество. =)

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

>> отсутствие сопоставления с образцом

> поясните.

ы? http://en.wikipedia.org/wiki/Pattern_matching, см. так же Haskell, Ocaml.

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

По словам очевидцев хорошее покрытие юнит-тестами спасает.

> По словам очевидцев хорошее покрытие юнит-тестами спасает.

Писать юнит-тесты для того, чтобы отловить ошибки типизации и банальные описки - это трата времени. Кроме того, 100% покрытие тестами достигается редко, и даже оно может не спасти.

> ы? http://en.wikipedia.org/wiki/Pattern_matching, см. так же Haskell, Ocaml.

сори, не заметил, что вы написали pattern matching в предыдущем посте, бо выр-е "сопоставление с образцом" у меня почему-то ассоциироваллось с перловыми билдин регекспами.

насчёт патерн матчинг - кто вам сказал, что в питоне этого нет? =)

> насчёт патерн матчинг - кто вам сказал, что в питоне этого нет? =)

Злые люди :D

Итак - прошу привести список языковых конструкций pattern matching в Питоне 8)

> Писать юнит-тесты для того, чтобы отловить ошибки типизации и банальные описки - это трата времени.

Писать то всё равно надо, если по-хорошему.

> Кроме того, 100% покрытие тестами достигается редко, и даже оно может не спасти.

Ну на 100% правильно никто не пишет.

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

http://www.wilmott.ca/python/patternmatching.html

Его сделали не в микросакс.

> Писать юнит-тесты для того, чтобы отловить ошибки типизации и банальные описки - это трата времени. Кроме того, 100% покрытие тестами достигается редко, и даже оно может не спасти.

Если проект большой, а ошибки обходятся дорого, без юнит-тестов ты в любом случае не обойдёшься. А статическую проверку кода никто не отменял, есть pychecker и pylint, иди осиливай. Pylint можно обучить практически всему, что умеет компилятор явы или плюсов, была бы необоходимость.

>> Писать юнит-тесты для того, чтобы отловить ошибки типизации и банальные описки - это трата времени.

> Писать то всё равно надо, если по-хорошему.

Но не для отлова же того, что должен ловить компилятор

> У динамической типизации не только минусы, кому бы она тогда была нужна

Я знаю

> Статическая ведь и реализуется проще

O_O ровно наоборот

> http://www.wilmott.ca/python/patternmatching.html

Ну да, сделаем из Питона еще один Си++, только хуже. _Такой_ pattern matching есть в любом языке.

так простите, pyhton - не функциональный язык с богатыми функциональными, декларативными, литеративными и проч. возможностями. это лёгкий *скриптовый* язык для повседневного использования a la налобать гуй за пару минут, налобать скриптик, написать проект под web. это не серебрянная пуля, это не решение вселенский проблем, это просто just another not bad language. всё.

>это лёгкий

O_O Да ну?

> O_O Да ну?

хм, в плане освоения =)

libpython2.5.so на моей 64-битной системе занимает чуть больше мегабайта. Это много?

>в плане освоения =)

Если только :)

> Ога, сегодня ты хочешь паттерн-матчинг, завтра захочешь интерфейсы, послезавтра - встроенные регекспы и корованы искаропки. Руки прочь от Питона, лучше иди рубистам давай советы, один чёрт ихнему недоязычку скоро помирать.

Хорошо сказал :_)

Ну это если не учитывать туеву хучу "батареек" идущих в комплекте

> это лёгкий *скриптовый* язык для повседневного использования a la налобать гуй за пару минут, налобать скриптик

а... ну так бы сразу и сказал.

> то не серебрянная пуля, это не решение вселенский проблем

а что, статическая типизация и pattern matching автоматом переводят язык программирования в категорию средств решшения "вселенских проблем"? o_O

http://shootout.alioth.debian.org/gp4/benchmark.php?test=all&lang=python&...

> а что, статическая типизация и pattern matching автоматом переводят язык программирования в категорию средств решшения "вселенских проблем"? o_O

просто если тред почитать, то в python должны быть реализованы и патерн матчинг, и компиляция, и статическая типизация. требования завышены =)

> Но не для отлова же того, что должен ловить компилятор

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

> O_O ровно наоборот

Почему? Если статическая типизация - к переменной привязываем тип и проверяем. Тип известен, сразу можно писать нужный код. например a + b для int-ов будет ADD, для строк вызываем функцию конкатенации. А вот если динамическая - для каждого значения таскаем тег, в код везде вставляем switch-и. И, по-хорошему, надо от этого по мере сил и возможностей избавляться, проводить сложный анализ, т.е. исскуственно типизировать. Имхо это значительно сложнее.

> Ну это если не учитывать туеву хучу "батареек" идущих в комплекте

Не нравится - не пользуйся. Если тебе надо ембеддед - возьми только необходимые модули, можешь ещё в zip запаковать. Или freeze/py2exe/whatever.

Во всяком случае, на моём древнем заурусе питон прекрасно себя чувствует.