Я довольно долго присмаривался к Python И в конце концов выстроил свой список того что мне в нем нравиться (ну что привлекает) и что не нравиться.
Итак начну стого что все таки не нравиться:
1). Отсутствие опратора new. Что создание объекта что вызов функции выглядит одиноково. И в больших проектах если нет соглашения о именовании (такое конечно вряд ли возможно), то это вообщем то становиться проблемой — код становиться читать сложно.
2). GIL. Когда я только подходил к изучению Python мне говорили что вот тут то с потоками все ништяк Все круто и супер, фиг вам. На большом количестве потоков громадное проседание производительности. PS огромное количество потоков я не использую, просто как результат моих бенчмарков
3). Отсутствие интерфейсов.
4). Создание статических методов класса как мне кажеться до сих пор (а я рассматриваю версию 2.5) до сих пор как мне видиться сделано через жопу (в виде докораторов), про более низкие версии вообще умолчу.
5). Невозможность объявить приватный конструктор. Это бывает нужно когда инстанцирование объекта происхоит через статический метод (фабрику) И по другому объекты создавать нельзя.
6). Как мне кажеться совершенно смелый и неудобный синтаксис. Я вот например принадлежу к числу тех кто пишет так:
if(...)
{
}
а не так :
if(...){
}
По началу было непривычно и до сих пор неприятный осадок остался особенно учитывая что я использую не только Python но и языки где опреаторные скобки все таки присутствуют (C++ например
7). Отсутствие нормальносо С-ного цикла for
8). Последующие версии интерпритатора несовместимы со старым кодом. Не то что бы уж очень сильный минус но все же.
Теперь перейду к перчню того что нравиться:
1). Поддрежка исключений
2). Наличие psycho (это своеобразный JIT компилятор учитывающий диманику языка)
3). Он очень легко расширяеться сишными модулями. Это действительно делать легко. Не ну например сейчас накатать XS код для perl для меня не проблема но по началу были трудности а здесь их нет, чне несомненный плюс
4). Его используют продвинутые компании наподобии google. Это лично для меня весомый аргумент (почему то ведь они его используют)
5). Язык бурно развивается (но на мой сугубо личный взгляд совершенно не в ту сторону). 3 Питон совершенно меня разочаровал, при том что проигрывает в скорости 2.5 на 25% о чем на Официальном сайте прямо сказано.
6). У Python развитая инфраструктура библиотек, качестов когда правда у некоторых страдает, но счаз не об этом
7). Большое комьюнити
8).На нем мона писать десктопные приложения. Ну очень большие, (большие страшновато), но можно. Хотя это не особо плюс скорее как фича
9). Наличие докораторов, который позволяют напрямую подойти к аспектному програмированию, наиболее лаконично и естественно.
Нравится не нравится это очень субъективно, но все равно хочу немножко прокомментировать
M>1). Отсутствие опратора new. Что создание объекта что вызов функции выглядит одиноково. И в больших проектах если нет соглашения о именовании (такое конечно вряд ли возможно), то это вообщем то становиться проблемой — код становиться читать сложно.
Мне кажется в русле идеологии питона так и должно быть, оператор new просто не нужен, причина и функции и классы первоклассные ( ) объекты и кстати по сути создание объекта в питоне это как раз вызов оператора __call__ для метакласса
M>2). GIL. Когда я только подходил к изучению Python мне говорили что вот тут то с потоками все ништяк Все круто и супер, фиг вам. На большом количестве потоков громадное проседание производительности. PS огромное количество потоков я не использую, просто как результат моих бенчмарков
Да GIL это плохо. Хотя на огромном количестве потоков и без GIL'а будет сильное проседание.
M>3). Отсутствие интерфейсов.
Ну в 3.0 уже есть. В 2.x при большом желании делается на метаклассах, но опять это не в русле питона.
M>4). Создание статических методов класса как мне кажеться до сих пор (а я рассматриваю версию 2.5) до сих пор как мне видиться сделано через жопу (в виде докораторов), про более низкие версии вообще умолчу.
Декораторы там только внешняя часть айсберга
На самом деле и методы класса и свойства сделаны через дескрипторы (можно тут глянуть http://www.iso.ru/journal/articles/print/143.html) этот механизм довольно интересный и мощный.
M>5). Невозможность объявить приватный конструктор. Это бывает нужно когда инстанцирование объекта происхоит через статический метод (фабрику) И по другому объекты создавать нельзя.
Метаклассы спасут отца руской демократии
.............
M>По началу было непривычно и до сих пор неприятный осадок остался особенно учитывая что я использую не только Python но и языки где опреаторные скобки все таки присутствуют (C++ например
Попиши на лиспе
M>7). Отсутствие нормальносо С-ного цикла for
Да еще то что ты относишь 1, 3, 4, 5 к минусам показывает что ты не до конца вкурил объекты в питоне. Это не совсем одно и тоже что объекты в С++/Java. В питоне объекты от Алан Кэя, а не от Гради Буча
M>1). Отсутствие опратора new. Что создание объекта что вызов функции выглядит одиноково. И в больших проектах если нет соглашения о именовании (такое конечно вряд ли возможно), то это вообщем то становиться проблемой — код становиться читать сложно.
Не нужен. Не становится. Первое проистекает из идеологии питона (классы, как объекты), второе — из опыта больших проектов на нем.
M>3). Отсутствие интерфейсов.
Интерфейсов, что бы что? Язык динамический, объект может сделать с собой что угодно — удалить метод, добавить метод. Если вам хочется интерфейсов, всегда можно их эмулировать, но смысла нет.
M>4). Создание статических методов класса как мне кажеться до сих пор (а я рассматриваю версию 2.5) до сих пор как мне видиться сделано через жопу (в виде докораторов), про более низкие версии вообще умолчу.
В общем-то, статические методы сделаны вполне логично в рамках языка, да и неудобств написать @classmethod я не вижу.
M>5). Невозможность объявить приватный конструктор. Это бывает нужно когда инстанцирование объекта происхоит через статический метод (фабрику) И по другому объекты создавать нельзя.
Понимаете, когда в языке что-то нельзя сделать так, как написали гамма сотоварищи, это не всегда проблема языка. В некоторых языках и классов с объектами нет, например, а они от этого только выигрывают.
M>6). Как мне кажеться совершенно смелый и неудобный синтаксис. Я вот например принадлежу к числу тех кто пишет так:
Ну это вкусовщина; в общем-то это снижает количество писанины (но за это приходится платить).
M>7). Отсутствие нормальносо С-ного цикла for
Зачем? И чем это питоновский for ненормален? Т.е. си-стайл for — это жалкая поделка по сравнению с питоновским for, зачем
бы он мог понадобиться — приведите пример?
M>2). Наличие psycho (это своеобразный JIT компилятор учитывающий диманику языка)
Который выжирает кучу памяти и дает очень слабый прирост, так что, например, на сервере от него один вред, кроме того, он не поддерживает и не будет 64-битные системы.
M>3). Он очень легко расширяеться сишными модулями.
Ну это много кто умеет, тут скорее перл отличился просто.
M>4). Его используют продвинутые компании наподобии google. Это лично для меня весомый аргумент (почему то ведь они его используют)
Это вообще не аргумент — все говорят, что гугл его использует, но мало кто знает зачем. Может, например, они его используются для сборки проектов в scons?
M>5). Язык бурно развивается (но на мой сугубо личный взгляд совершенно не в ту сторону).
Это да. Бурно и не туда.
Из недостатков:
1) Динамическая типизация
2) Отсутствие системы типов
3) Отсутствие компиляции в натив
4) Отсутствие (и врядли будет нормальный) JIT
5) Отсутствие оптимизации хвостовой рекурсии
6) package hell
7) Отсутствие стандартного (входящего в стандартный тулчейн) механизма сборок (подобие линковки, что бы можно было выкатить некий пакет или бинарник, где будут слиты все пакеты, которые вы используете для своего приложения)
8) Еще и тормозной
M>>4). Его используют продвинутые компании наподобии google. Это лично для меня весомый аргумент (почему то ведь они его используют)
dmz>Это вообще не аргумент — все говорят, что гугл его использует, но мало кто знает зачем. Может, например, они его используются для сборки проектов в scons?
Re: Что мне "не нравиться"/ нравиться в Python M>3). Отсутствие интерфейсов.
M>3). Интерфейсов, что бы что? Язык динамический, объект может сделать с собой что угодно — удалить M>3). метод, добавить метод. Если вам хочется интерфейсов, всегда можно их эмулировать, но смысла нет.
Зачем??? Зачем динамически вообще что то добавлять? Это может быть круто для локальных решений. Но например мое имхо это сильно препятствует портированию кода на другие языки, если допустим кусок кода придеться переписывать на С. Опят в таких случаях приходиться подставлять костыли. Короче жутко неодобно.
M>4). Создание статических методов класса как мне кажеться до сих пор (а я рассматриваю версию 2.5) до M>3). сих пор как мне видиться сделано через жопу (в виде докораторов), про более низкие версии вообще M>3). умолчу.
M>3). В общем-то, статические методы сделаны вполне логично в рамках языка, да и неудобств написать M>3). @classmethod я не вижу.
Я в принцепе с вами согласен. Но чем слово зарезервированое для декларации методов хуже. К тому же декораторы работают уже в рантайме, что не еть на мой взгляд хорошо, когда такие ситуации можно отловить на уровне компиляции
M>5). Невозможность объявить приватный конструктор. Это бывает нужно когда инстанцирование объекта M>5). происхоит через статический метод (фабрику) И по другому объекты создавать нельзя. M>5). Понимаете, когда в языке что-то нельзя сделать так, как написали гамма сотоварищи, это не всегда M>5). проблема языка. В некоторых языках и классов с объектами нет, например, а они от этого только M>5). выигрывают.
Каждый язык подходит в конкретных задачах, Питон как я заключил из форумов и рассылок, рассматриваеться как универсальное средство. В любом случаа вот приходит в команду новый человек который про инфраструктуру не знает толком ещё (да еть WIKI и прочие системы документирования). Но вот этот гипотетический человек пытаеться инстанцировать объекты не так как я зудумал. И что мы наблюдаем в питоне он благополучно его создает через конструктор, а грубли вылезут через дня 2 3, хотя их вообще могло бы не быть.
M>7). Отсутствие нормальносо С-ного цикла for M>7). Зачем? И чем это питоновский for ненормален? Т.е. си-стайл for — это жалкая поделка по сравнению с M>7). питоновским for, зачем M>7). бы он мог понадобиться — приведите пример?
Ну напремер для итерации по моссиву через 2 или 3 элемента
M>2). Наличие psycho (это своеобразный JIT компилятор учитывающий диманику языка) M>2). Который выжирает кучу памяти и дает очень слабый прирост, так что, например, на сервере от него M>2). один вред, кроме того, он не поддерживает и не будет 64-битные системы.
Вот это да ( Вы меня очень расстроили в плане памяти и общей производительности. По бенчмаркам psycho показывал очень нелохие результаты(
Из недостатков:
>>>1) Динамическая типизация >>>2) Отсутствие системы типов
это уже идеология языка
>>> 3) Отсутствие компиляции в натив >>> 4) Отсутствие (и врядли будет нормальный) JIT
Как мне кажеться это невозможно для динамический языков. Хотя вот у mozilla вот tracemonkey появился. Есть parrot, который таки обещают закончить к марту будущего года (и всего то через 9 лет Разработки)
>>> 5) Отсутствие оптимизации хвостовой рекурсии
Тут сказать мне что то сложно. Но по сути это если уж совсем припрет переписываеться на итеративный алгоритм.
>>>6) package hell
M>Зачем??? Зачем динамически вообще что то добавлять? Это может быть круто для локальных решений. Но например мое имхо это сильно препятствует портированию кода на другие языки, если допустим кусок кода придеться переписывать на С. Опят в таких случаях приходиться подставлять костыли. Короче жутко неодобно.
В питоне — удобно, т.к. язык динамический. На си он не переписывается, да и незачем. На си надо писать в стиле си, на питоне — в стиле питона.
M>Я в принцепе с вами согласен. Но чем слово зарезервированое для декларации методов хуже. К тому же декораторы работают уже в рантайме, что не еть на мой взгляд хорошо, когда такие ситуации можно отловить на уровне компиляции
Декораторы работают, скорее всего, при инстанциации модуля, т.е. даже не при создания экземпляра класса. Так что не страшно. А "в компайл тайм" в питоне вообще почти ничего не отлавливается, т.к. язык динамический.
M>Каждый язык подходит в конкретных задачах, Питон как я заключил из форумов и рассылок, рассматриваеться как универсальное средство. В любом случаа вот приходит в команду новый человек который про инфраструктуру не знает толком ещё (да еть WIKI и прочие системы документирования). Но вот этот гипотетический человек пытаеться инстанцировать объекты не так как я зудумал. И что мы наблюдаем в питоне он благополучно его создает через конструктор, а грубли вылезут через дня 2 3, хотя их вообще могло бы не быть.
Скорее всего, если он может вызвать объекты не так, как задумано и при этом что-то сломается — значит это просчет дизайна. Вероятно, в питоне делается не так, как написано в книжке, а, например, через метаклассы. Ну или делать так, что бы конструктор всегда порождал валидный экземпляр.
M>Ну напремер для итерации по моссиву через 2 или 3 элемента
xrange(0,10, step=2)
>>>> 5) Отсутствие оптимизации хвостовой рекурсии
M>Тут сказать мне что то сложно. Но по сути это если уж совсем припрет переписываеться на итеративный алгоритм.
А если вообще совсем припрет — то переписать все на окамле, ага. Попутно поимев сокращение кода с 2300 строк до 517 (это из последнего проекта).
M>есть такое дело. Но в perl мо моему не лучше.
Здравствуйте, meandr, Вы писали:
M>Re[2]: Что мне "не нравиться"/ нравиться в Python M>А вы это использовали? Как я понимаю что это просто python хоитнг от google??
Как у вас так интересно цитировать получается?
А по ссылке собственно достаточно информации, на мой взгляд.
По сути да, что-то вроде хостинга, но насколько я понимаю это же дело гугл сам использует, к примеру Google Moderator
Здравствуйте, meandr, Вы писали:
M>Каждый язык подходит в конкретных задачах, Питон как я заключил из форумов и рассылок, рассматриваеться как универсальное средство. В любом случаа вот приходит в команду новый человек который про инфраструктуру не знает толком ещё (да еть WIKI и прочие системы документирования). Но вот этот гипотетический человек пытаеться инстанцировать объекты не так как я зудумал. И что мы наблюдаем в питоне он благополучно его создает через конструктор, а грубли вылезут через дня 2 3, хотя их вообще могло бы не быть.
Code review у вас совсем не используется?
Тем более для "новичков"?
Здравствуйте, dmz, Вы писали:
dmz>Интерфейсов, что бы что? Язык динамический, объект может сделать с собой что угодно — удалить метод, добавить метод. Если вам хочется интерфейсов, всегда можно их эмулировать, но смысла нет.
Смысл есть, например если строится компонентная модель, то эмулируемые интерфейсы
1) описывают статический контракт на самом языке Python
2) используются для того чтобы во время выполнения программы узнать какие контракты поддерживает компонент
Здравствуйте, DemAS, Вы писали:
>> 2) используются для того чтобы во время выполнения программы узнать какие >> контракты поддерживает компонент
DAS>"Если объект ведет себя как утка — это утка". Примерно так. Точную цитату не помню.
DAS>Если хочется проверить — поддерживает ли объект контракт — просто вызови его методы и посмотри что произойдет.
Что если нужно знать о наличии набора методов?
Что если нужно знать о поддержке контракта до вызова метода?
Здравствуйте, achmed, Вы писали:
A>Что если нужно знать о наличии набора методов? A>Что если нужно знать о поддержке контракта до вызова метода?
Узнать до вызова без проблем — hasattr, да и вообще развитая интроспекция.
Вот обратный вариант — заставлять подерживать контракт это противоречит философии
динамических языков, но в python 2.6 (и 3.0) пошли на уступку любителям
статического ООП и ввели абстрактные классы: http://www.python.org/dev/peps/pep-3119/
В принципе там все сделано на метаклассах и можно делать подобное
или свой вариант и для более раних версий:
Здравствуйте, FR, Вы писали:
FR>Узнать до вызова без проблем — hasattr, да и вообще развитая интроспекция.
А если имя метода просто совпадает а объект и не думает поддерживать контракт? Тогда нам нужно хранить дополнительный маркер "я поддерживаю контракт X"
FR>Вот обратный вариант — заставлять подерживать контракт это противоречит философии FR>динамических языков,
не понимаю противоречия, статический контракт определяется на этапе проектирования,
реализация контракта в python объекте может быть сделана на этапа разработки или
на этапе выполнения за счет динамики.
FR>но в python 2.6 (и 3.0) пошли на уступку любителям FR>статического ООП и ввели абстрактные классы: FR>http://www.python.org/dev/peps/pep-3119/
Здравствуйте, achmed, Вы писали:
A>А если имя метода просто совпадает а объект и не думает поддерживать контракт? Тогда нам нужно хранить дополнительный маркер "я поддерживаю контракт X"
С такими мыслями лучше писать на статических языках (исключая ocaml )
Почему-то я не припомню ни одной подобной ошибки за пару лет активной работы на питоне.
FR>>Вот обратный вариант — заставлять подерживать контракт это противоречит философии FR>>динамических языков,
A>не понимаю противоречия, статический контракт определяется на этапе проектирования, A>реализация контракта в python объекте может быть сделана на этапа разработки или A>на этапе выполнения за счет динамики.
Если очень хочется конечно можно.
FR>>но в python 2.6 (и 3.0) пошли на уступку любителям FR>>статического ООП и ввели абстрактные классы: FR>>http://www.python.org/dev/peps/pep-3119/
A>Даже не знаю, хорошо это или плохо. То что делалось с помощью метапрограммирования меня вполне устраивало.
Здравствуйте, meandr, Вы писали:
M>Я довольно долго присмаривался к Python И в конце концов выстроил свой список того что мне в нем нравиться (ну что привлекает) и что не нравиться.
я вот закончил читать ман и почти дописал свой небольшой, но очень гордый скриптик
M>Итак начну стого что все таки не нравиться: M>1). Отсутствие опратора new.
мне оказалось это пофиг..
всё равно читать приходится всё.. и вот это имхо минус..
очень сложно пробежаться по коду глазами и понять что оно вообще делает..
M>3). Отсутствие интерфейсов.
не страшно, но труднее понять кем представляется данный объект..
M>6). Как мне кажеться совершенно смелый и неудобный синтаксис. Я вот например принадлежу к числу тех кто пишет так:
синтаксис смутил лишь частично..
очень не понравилось, что непонятно что вернет функция..
еще "эти ваши гребаные иденты" подсунули свинью при копипасте кода.. очень неприятно..
M>7). Отсутствие нормальносо С-ного цикла for
да, сначала удивляет, потом привыкаешь..
но я всё равно считаю это недостатком для некого сферического цикла использовать списки имхо некрасиво..
но лично мне больше всего не понравилось то, что можно создавать мемберы классов прямо в процессе работы.. имхо это дырка для всяческих нубских хаков.. и мне не хочется с таким сталкиваться..
M>Теперь перейду к перчню того что нравиться:
а мне в принципе он почти весь понравился.. низкий порог вхождения, мало синтаксиса, удобная система пакетов.. хорошая репутация в сравнении с php
думаю, буду использовать его в работе по мере необходимости..
Все круто и супер, фиг вам. На большом количестве потоков громадное проседание производительности. PS огромное количество потоков я не использую, просто как результат моих бенчмарков
( Вы меня очень расстроили в плане памяти и общей производительности. По бенчмаркам psycho показывал очень нелохие результаты
