×Закрыть

Использование языка Python для разработки научно-технического программного обеспечения

Предисловие

В этой статье мы рассмотрим преимущества и недостатки использования языка Python в научно-инженерных приложениях как альтернативы традиционным C, C++, Fortran и, прежде всего, MATLAB, Octave и другим математическим пакетам. Она написана по мотивам одноименного семинара, прошедшего 2009−02−05 в институте кибернетики НАНУ. Там я допустил ряд оговорок, которые и собираюсь исправить в этой статье (перед докладом присутствующие попросили сократить его с предложенных мне начальством и планировавшихся 40−60 минут до 30, что сказалось на качестве, к тому же, наверное, повлияло то, что с самого утра и до доклада в 15−00 я так и не успел ничего поесть:)). Тезисы упомянутого семинара можно скачать здесь.

Статья написана по просьбе developers.org.ua и, соответственно, выдержана в стиле других статей с этого сайта.

Мотивация

Почему вообще стоит тратить время на изучение Python (и, более того, писать на нем научное ПО), когда и так есть С/C++, Fortran, MATLAB/Octave, с достаточным количеством соответствующего ПО, более того, обычно бесплатного?

Прежде всего, низкоуровневые языки, такие как С, C++, Fortran, Assembler, не позволяют RAD (Rapid Application Development — быстрая разработка приложений). Приходится тратить много времени на компиляцию и линкование, а пользоваться отладчиком многие не умеют (особенно школьники и студенты). Кроме того, и С, и Fortran являются «Write Only Language» (особенно это актуально для Perl, где написанный код понимает только его автор, и то обычно не дольше 15 минут). Как правило, часто требуется также синхронизация (автоматическая или ручная) header-ов (h, hpp и тп) и source-файлов (с, cpp и тп). Очень часто встречаются runtime-ошибки «выход за границу массива», которые неопытным пользователям тяжело как находить, так и не допускать. На сайте mloss.org, где из уже более 170 пакетов относительно нового научно-технического направления (machine learning), нет ни одного (!) пакета, написанного на Fortran. Также, низкоуровневые языки не являются кросс-платформенными.

Одной из составляющих RAD-свойств Python является отсутствие строгой типизации. Посмотрим, например, на следующую функцию:

def myFunc(a, b): 
    return 2*a + b 

Здесь нам не требуется указывать типы аргументов a и b, это может быть все, что только позволяет делать операции суммы и умножения на 2 без ошибок: это могут быть числа, число и матрица из numpy, строки, списки, матрицы одинаковой размерности, объекты какого-либо класса пользователя, с учетом того, что он определил операции сложения и умножения на число.

Выучить Python несложно даже школьнику за пару недель, чего нельзя сказать про C/С++, Fortran, Ocaml, Erlang. По оценкам специалистов, разработка приложений на Python примерно в 2 раза быстрее, чем на Fortran, кроме того, написанные программы содержат намного меньше строк кода и более читабельные, что позволяет легче вносить изменения. А ведь это не только зарплаты программистов, но и аренда помещений, зарплата другим сотрудникам организаций, да и просто опережение конкурентов и своевременное выполнение сроков. Опыт моей работы в коммерческих фирмах свидетельствует, что очень часто между софтверной организацией и потенциальным заказчиком проходит следующий диалог: «Ваше ПО считает задачу за 30 секунд. За 5000$ мы можем написать ПО, которое будет считать ее за 3 секунды. » — «А нам не надо считать ее за 3 секунды, мы считаем ее раз в неделю, а через месяц мы купим новый процессор за 500$ и будем считать ее за 15 сек. »

Рассмотрим теперь высокоуровневые языки. MATLAB, MAPLE, MATCAD, Mathematica довольно дорогие. Конечно, сейчас у нас нетрудно приобрести нелицензионную версию, но:

  • это не гарантирует, что такая ситуация будет продолжаться всегда;
  • кроме приличной цены, требуется еще и платить ~10% в год за обновления библиотек
  • за границей (Китай, Бразилия и т. п., особенно Европа, в которой более строго с нелицензионным ПО), где осознали всю негативную сторону зависимости от коммерческого ПО, начинается мощное движение о переходе на свободное ПО в образовании, муниципальных и других государственных структурах. Со временем это приведет к улучшению качества СПО, так что миграция и программистов, и заказчиков, и пользователей только ускорится. Поэтому сделавшие ставку на эти коммерческое пакеты в будущем могут об этом пожалеть, т. к. качественно переписать тысячи строк кода (тем более, научного-технического), особенно если организация не распологает квалифицированными в обоих языках специалистами — задача непростая и технически, и финансово.

Кстати, уже хотя бы поэтому тем программистам, у кого есть способности в точных науках, и стоит устраиваться на работу в научно-технические проекты, требующие высокой технической квалификации — меньше вероятность, что заказчик через какое-то время решит сменить разработчика всех этих сайтов, веб-приложений, GUI и т. п. на каких-нибуть школьников из Индии или Китая, способных (и согласных) выполнять ту же работу в 2−3 раза дешевле. А вы еще не задумывались, сколько в Индии или Китае таких школьников?

Отметим также, что даже несомненный лидер из матпакетов — MATLAB — также обладает рядом недостатков:

  • необходимость заканчивать каждую строку кода символом «; »;
  • отсутствие компилятора в машинный код;
  • неудобная стыковка с другими языками программирования (С, Fortran) посредством mex- функций;
  • неудобная обработка строк и ряда других типов, в том числе классов ООП;
  • передача аргументов копированием;
  • очень высокая цена (на сегодняшний день для фирмы, без скидок — 3000$ за MATLAB + цены за тулбоксы, например Optimization toolbox — 1562$, по прайс-листу softline.ru). Конечно же, как и почти любой другой уважающий себя продукт коммерческого ПО, MATLAB имеет паучьи сети, которые в Mathsoft обычно называют студенческими скидками;

Как очень точно было отмечено в одном из сообщений MATLAB mail-list, Octave, SciLab и т. п. — это посредственная имплементация языка MATLAB, который, в свою очередь, посредственная реализация всего кроме матриц. Однако следует признать, что за последние 2 года некоторые недостатки MATLABа были исправлены.

Что касается Octave и особенно SciLab, стоит также упомянуть проблемы с лицензией. Для Octave это GPL, содержащая copyleft (который запрещает использовать в лицензии своего продукта более сильные ограничения, чем ограничения используемых в нем библиотек с copyleft), для SciLab она вообще не является OSI-approved. Это очень сильно сдерживает их распространение и развитие, т. к. ряд организаций, выпускающих коммерческое ПО, не использует их, предпочитая продукты без copyleft (т. е. c такими лицензиями как BSD, MIT, Apache).

Вообще, по наблюдениям автора, общая тенденция в развитии программного обеспечения (в т. ч. научного) такая: свободное ПО постепенно вытесняет коммерческое, тогда как свободное ПО без copyleft постепенно вытесняет содержащее copyleft (за счет того, что более охотно получает финансовую поддержку от софтверных организаций). Типичный пример — широко распространенные библиотеки BLAS и LAPACK. Для ряда другого, более сложного научного ПО, например численная оптимизация, коммерческое ПО пока еще сохраняет свои позиции, но все же на мой взгляд это только вопрос времени — уже сейчас такие бесплатные решатели как IPOPT или DSDP показывают результаты на уровне коммерческого ПО стоимостью в тысячи долларов. Стоит отметить, что основной финансовой основой для развития научного СПО являются гранты от научных фондов, университетов, ряда организаций (IBM, Sun Microsystems и т. п.).

Что касается использования других высокоуровневых языков в научно-технических целях, то недостатки у них следующие:

  • OCAML — лицензия (GPL), сложность изучения.
  • Ruby — низкая скорость (в 2−4 раза меньше Python), популярность в основном благодаря ROR (библиотека для разработки web-приложений), отсутствие множественного наследования, неопределенность в выборе наиболее быстрого подхода к написанию участков кода.
  • Java — этот язык более низкого уровня чем Python, Ruby, MATLAB, поэтому разработка приложений занимает больше времени.
  • Groovy, Cobra (не путать с CORBA) и другие клоны Python — в первую очередь небольшое кол-во написанного для них ПО. Не так уж сложно взять за основу какой-нибуть из существующих языков и исправить несколько его недостатков, но, как особенно любят говорить Java-программисты, язык без батареек сейчас никому не нужен. Кстати, одним из слоганов Python как раз и является «Batteries included» — т. е. к языку прилагается множество программных модулей.
  • F# — уже сам факт того, что за ним стоит Microsoft, отпугивает многих пользователей (и, следовательно, уменьшает аудиторию и распространение языка). В половине F# FAQ автор неубедительно пытается откреститься от Microsoft и возможных лицензионных проблем. Кроме того, на мой взгляд, F# не полностью избавился от недостатков OCAML.
  • R — лицензия (GPL), узкая основная направленность (стохастическая), не очень удобный синтаксис.
  • Что же касается Pascal, по мнению автора, в школах и некоторых ВУЗах Украины его учат просто по инерции, никаких особых достоинств по сравнению с конкурентами у него давно уже нет.

Кроме того, почти все упомянутые здесь языки (кроме разве что R), так же как и PHP, tcl (в которых к тому же приходится писать надоедливый знак «$», а в случае PHP — еще и «; »), имеют очень небольшое кол-во научного ПО (по сравнению с Python, включая ПО с Python-интерфейсами).

Основные недостатки языка Python

Как и любого другого языка программирования, у Python конечно же есть и свои недостатки:

  • Python изначально не предназначался для научно-технических задач, впрочем как и С/С++. Поэтому его программные конструкции в этом плане оставляют желать лучшего, так же как и скорость (что частично компенсируется numpy и удобством подключения кода других языков, см. ниже).
  • В отличие от MATLAB, Octave и ряда другого ПО, в Python нет стандартной библиотеки для разреженных матриц: кто-то пользуется scipy.sparse, кто-то PySparse, кто-то (как CVXOPT) использует свои библиотеки и/или BLAS, кто-то просто 3 столбца (координаты числа и его значение). По мнению автора, отказ разработчиков scipy включить разряженные библиотеки (их автору) в numpy был большой ошибкой, иначе сейчас это уже было бы единым стандартом.
  • В настоящее время Python проходит болезненную миграцию с версии 2.5 до 2.6 и далее 3.0, где очень много изменений. Есть программы, которые позволяют делать это автоматически, но на numpy и scipy, которые имеют значительную часть кода C и Fortran, это не распространяется. Подробнее см. здесь. По-видимому, именно с этим связано локальное снижение популярности Python в TIOBE index.
  • Выделение блоков основано на индентации. Некоторые пользователи (в т. ч. я) это любят, остальные — наоборот, терпеть не могут.

Основные дистрибутивы Python

  • CPython — основная имплементация Python на языке С, выполненная автором Python Guido van Rossum. Он занимает более 90% от всех имплементаций.
  • Jython — имплементация Python на Java. Изначально на нее полагались большие ожидания, но ничего особенного она так и не показала, во многом из-за не очень большой скорости и несовместимостью со многими библиотеками, написанными под CPython.
  • IronPython — имплементация Python под Microsoft. NET. Имеет свой контингент пользователей, но в первую очередь Microsoft занята продвижением конкурирующегос Python языка С#.
  • PyPy (PythonPython) — экспериментальная имплементация, выполнявшаяся несколько лет коллективом, спонсированным одним из грантов FP7. Вряд ли у него есть будущее (из-за несовместимости с библиотеками CPython), но его наработки (динамическая трансляция некоторых участков кода в С и их компиляция «на лету») возможно, в будущем будут использованы в CPython.
  • PyMite — имплементация Python для ряда микропроцессоров (в первую очередь Atmel).

Основные научные библиотеки Python

Прежде всего, следует отметить numpy (numeric python, numpy.scipy.org) и scipy (scientific python, scipy.org), см также их страницы на wikipedia.org: NumPy, SciPy. Они (и их списки почтовых рассылок — numpy-user, scipy-user, scipy-dev, см. scipy.org/Mailing_Lists) являются «точками сбора» всех пользователей Python в научно-технических целях (впрочем, стоит отметить также SAGE google groups).

  • NumPy — это низкоуровневая библиотека, написанная в основном на С и Фортран (в основном матричные операции), опирается на код BLAS+ATLAS, LAPACK. См также «NumPy для пользователей MATLAB»: www.scipy.org/NumPy_for_Matlab_Users. Тем, у кого проблемы с английским, могу порекомендовать вставить этот html-адрес в translate.google.com или аналогичный сервис.
  • SciPy — численное интегрирование, сплайны, оптимизация, решения систем диф. уравнений и т. п. Впрочем, иногда отдельные специализированные пакеты обладают бОльшим удобством, функциональностью и т. п (например, OpenOpt vs scipy.optimize).
  • В качестве аналога MATLAB plot tool наиболее распространен matplotlib

Рекомендуется посмотреть на следующие списки научного ПО для Python:

А также на голосование об использовании научных пакетов: www.doodle.com/...l?pollId=8mwqx63qecyem2np

Основные научные дистрибутивы Python

Можно вручную устанавливать Python и требуемые библиотеки, а можно вспользоваться одним из дистрибутивов, ориентированных на научное использование:

  • EPD (Enthought Python Distribution) — содержит numpy, scipy, matplotlib и многое другое, установка — практически в несколько кликов мышью. Недостатки: лицензия — free for non-commercial; платформы — только коммерческие Windows и RHEL, а прилагаемые к EPD IDE (IDLE и Scite) по функциональности могут конкурировать разве что с Microsoft notepad. Enthought является спонсором numpy/scipy.
  • SAGE — «свободная конкурентоспособная альтернатива MATLAB, MAPLE, MATCAD, Mathematica». В принципе, он соответствует этой характеристике, однако пользоваться им я бы не рекомендовал, в т. ч. даже в образовательных целях. Во-первых, для Windows требуется устанавливать VMWare. Во-вторых, сам SAGE занимает ~800 MB, компиляция занимает несколько часов. Средой разработки обычно выступает Mozilla Firefox с минимумом функциональности, рекомендуется разве что фанатам MATLAB Cells. Из плюсов следует отметить встроенные удобные интерфейсы к MATLAB, Octave, R и т. п.
  • PythonXY — дистрибутив, основанный на Eclipse (широкораспространенная бесплатная кроссплатформенная IDE, имеет плагины к Python). Дополнительные модули можно устанавливать как exe-файлы (также PythonXY доступен для Debian-based ОС Linux).

Воспользоваться хотя бы одним из этих дистрибутивов стоит уже хотя бы для того, чтобы избежать потенциальных проблем при установке numpy, scipy, matplotlib и т. п. (особенно это актуально, если нельзя воспользоваться apt-get, yum и другими утилитами для автоматического скачивания и установки в Linux). После этого можно установить предпочитаемую Python IDE (если содержащиеся в дистрибутиве по каким-то причинам не устраивают).

Основные среды разработки для Python

Прежде всего я рекомендовал бы обратить внимание на Eric, NetBeans, Eclipse, SPE.

Из известных мне IDE только Eric имеет Python Command Shell, аналогичную MATLAB Command Shell, поэтому именно его я бы рекомендовал в первую очередь (коммерческая Wing IDE имеет сразу 2 окна, из них одно для отладчика, по моему опыту это неудобно). Стоит отметить, что единственному разработчику Eric (Detlev Offenbach) удается поддерживать его функциональность и (немецкое) качество на уровне NetBeans, Eclipse (которые пишутся командами разработчиков при большой финансовой поддержке ряда корпораций), так же как и коммерческих KOMODO, Wing IDE. Кроме того, он потребляет всего 41 МБ RAM (Eclipse — 137, NetBeans 6.1/6.5 — 229/412). Время загрузки, сек — 4 — 21 — 16/25. Данные приведены для AMD Athlon 3800+ X2, Linux KUBUNTU. Один из доступных плагинов Eric проводит русификацию этой IDE.

Недостатком Eric являются проблемы с установкой, особенно с его зависимостями (лучше всего через apt-get, yum и другие Linux update channels установить все зависимости, а потом поставить сверху последнюю версию Eric, на вопрос о Qt data directory обычно помогает просто Enter. Если вместе с зависимостями вы установили и сам Eric, проверьте, какую версию вы запускаете (Help-> About Eric) и в случае старой версии измените путь на новую). Очень рекомендуется устанавливать версию не старее 4.3.0 (2009−02−08), т. к. там наконец-то были исправлены пара недостатков (по просьбе автора статьи) — прокрутка файловых вкладок доступна мышью, окно отладчика сразу переключается в locals; еще один недостаток- отсутствие возможности выполнения команд из текущей функции стека — Detlev пообещал исправить в 4.4.0, как и добавление визуальной системы ошибок и предупреждений, аналогичной MATLAB и NetBeans. Установка плагинов в Eric не очень удобна: Plugins-> Plugin Repository->update;download;install; Plugins-> Plugin Infos->activate, autoactivate. Прежде всего стоит установить pylint. Это менее удобно, чем в NetBeans, но более удобно чем в Eclipse, где к тому же установка плагинов почему-то выполняется через меню Help.

После установки Eric рекомендуется сразу же произвести начальную настройку — удалить подсветку текущего слова (если это еще не убрано в новой версии) и изменить цвет для подсветки результатов поиска с красного на какой-то получше, выставить типы файлов по умолчанию для сохранить/загрузить «py» (Python), удалить или переставить окно project-viewer, чтобы оно не мельтешило при включении/отключении отладчика, удалить с панели ненужные кнопки (например, для плагинов) и раздвинуть оставшиеся, чтобы была видна кнопка сохранения файлов. Впрочем, система hot-keys в Eric достаточно удобная, поэтому проще пользоваться ей, а не панелью.

Посмотреть на snapshot настроенного таким образом Eric можно здесь.

Все 3 рассмотренные среды разработки имеют conditional breakpoints, интеграцию с версионными системами (cvs, svn и тд) и практически полный спектр стандартных услуг. Полный список Python IDEs здесь.

Использование кода других языков в Python

Для подключения кода других языков в первую очередь рекомендуется:

  • Fortran — f2py (включен в numpy)
  • C/C++ — Python C API, SWIG, Pyrex, ctypes, cython. Последние два включены в numpy. Прежде всего стоит испольовать cython (Pyrex — его предшественник).
  • R — RPy
  • MATLAB — Mlabwrap. См. также дискуссию об автоматической трансляции m-файлов в Python
  • Assembler — CorePy

В NASA и ряде других организаций обычно практикуется следующий подход:

  • все, что можно, пишется на Python+numpy (конечно, используются и scipy, и другие библиотеки)
  • то, что требует большей скорости, пишется на Pyrex (сейчас уже Cython)
  • то, что требует еще большей скорости, пишется на C/С++, Fortran (и подключается через Cython. f2py)
  • то, что требует максимальной скорости, пишется на Assembler.

Если есть потребность в миграции проекта с С/С++/Fortran на Python, это обычно проходит «островным» способом — по очереди переписываются отдельные функции.

Заключение

У нас в продаже имеется достаточно переводной литературы по Python, к сожалению, литературы по NumPy (в переводе), насколько мне известно, пока нет, но для начального использования можно посмотреть несложные примеры из англоязычной документации. Как отмечают некоторые подписчики mail list (и мои собственные наблюдения — 3 года на MATLAB mail list и 2 года на numpy/scipy mail lists), на форумах СПО отвечают более подробно и охотно, чем на коммерческих — и действительно, зачем кому-то помогать Mathsoft зарабатывать деньги? И зачем авторам MATLAB оказывать бесплатную поддержку пользователям, когда они зарабатывают деньги на платной?

В странах СНГ все наступает с запаздыванием (по сравнению с Западом), по-видимому, это справедливо и для использования Python в научно-технических целях. Отсутствие строгого контроля за лицензионностью ПО замедляет внедрение СПО. Автор обращался в МОН с аналогичной аргументацией перевода образовательного процесса с MATLAB на Python, но, конечно же, безрезультатно — да и что ждать от министерства, у которого на сайте приводится адрес сотрудника, занимающегося распространением MATLAB и получающего с этого свои проценты.

Консультации по Python на русском/украинском языках можно получить на украинском сайте Python-программистов http://python.su. К сожалению, владельцы сайта отказались организовать подфорум — точку сбора (meetpoint) украинских пользователей Python в научно-технических целях, где (кроме тех. поддержки) софтверные организации могли бы набирать людей под свои проекты (возможно, с предварительным обучением). Они аргументировали это небольшим количеством соответствующих пользователей.

Если нет проблем с английским языком, то задавать вопросы по Python лучше здесь, скорее всего ответят быстрее и более квалифицированные специалисты. Стоит также отметить python-announce google group, где публикуются важные события (в основном выход новых релизов различных библиотек). Выход релизов научно-технических библиотек на Python (или, по крайней мере, с Python-API) обычно публикуется на scipy-user mail list.

Возможно, в будущем Python (так же как и С, Fortran, MATLAB) будет вытеснен Fortress или какими-то другими языками, однако сейчас его использование в научно-технических целях находится на подъеме (прежде всего имеются в виду страны Запада), о чем свидетельствует уже хотя бы резкое увеличение за последние 2 года трафика numpy-user и scipy-user mail lists. Однако этот язык наверняка будет высокоуровневым и производить передачу аргументов по ссылке, поэтому переписывать на него ПО проще всего именно с Python (по моему опыту миграции с MATLAB на Python двумя самыми большими проблемами были передача аргументов копированием и индексация массивов с единицы, в случае миграции Python-Fortress эти проблемы отсутствуют). О перспективном языке Fortress, которого его создатели из Sun Microsystems называют наследником Fortran, читайте в следующей статье автора.

См. также:

\\ by Dmitrey, и. о. м. н. с. отдела оптимизации ИК НАН Украины, openopt.org/Dmitrey.

  • Популярное

89 комментариев

Подписаться на комментарииОтписаться от комментариев Комментарии могут оставлять только пользователи с подтвержденными аккаунтами.

Если кому интересно — сегодня объявили о релизе средства для автоматической трансляции MATLAB-файлов в Python-файлыhttp://sourceforge.net/project.../Кстати — насчет коментов про точку с запятой — во-первых, не я добавлял их в каждом пункте, а Сергей Волошин (о чем он в 11 м коменте сам написал), во-вторых, я знаю очень немало людей, которые их терпеть не могут (в т.ч. я) — насчет «удалить с панели ненужные кнопки (например, для плагинов) » — тут я имел в виду, что они используются редко, а в случае чего можно использовать их из меню, так что на панели они только место зря занимают.

В Scilab есть похожее на Simulink средство, Scicos. Правда тормозит до ужаса на моей машине, по этому внимательно рассмотреть не получилось.

интересно, а аналог симулинка в scilab есть? просто матлаб ориентирован больше на численные методы чем на чистую математику, но если в scilab есть и то и другое то будет интересно его посмотреть...

SciLab и т.п. — это посредственная имплементация языка MATLAB

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

Комментарий по поводу статьи опубликовал в своем блоге http://xenru.livejournal.com/1...

В пункте «См. также дискуссию об автоматической трансляции m-файлов в Python» куда-то пропала ссылка, которую я приводил, вот онаhttp://comments.gmane.org/gman...

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

Да, а как он используется, вы видите? Совершенно не так, как ваш betterThan. И, всё-таки интересно, что же там память-то экономит.

я вот про это: > betterThan — вот я и говорю, что не хочу тратить лишнюю оперативную память на тело какой-либо функции в каждом объекте Point, а двойное подчеркивание делает синтаксис уродливым. Поэтому в scipy такой подход практикуется очень широко (т.е. заводят 2 функции — someFunc и someFunc)

> а где же его пара — метод array_data? а почему он должен иметь пару? > вместо ссылок на чужой код, лучше бы объяснили свойпро мой кода — я просто написал, что не только я пользуюсь double-underscore- методами, и что мне это рекомендовали разработчики scipy (не только для init, repr и т.п).А про «пару» — это я добавил betterThan (без «__» ) чтобы OpenOpt API не портить (этот метод используется из нескольких solvers, в т.ч. ralg, de, скоро будет и в нескольких других).

> assert t1.do==t2.doсорри, ошибся, там имелось ввиду assert id (t1.do) ==id (t2.do) > Советую вам в вашем примере вместо> assert t1.do==t2.do> выполнить> assert t1.do is t2.doзачем? > как насчет _arraydata__а где же его пара — метод array_data? вместо ссылок на чужой код, лучше бы объяснили свой:))

> Да, примеров там хватает, и ни один из них ничего общего с betterThan не имеет — pow, mul, retr, str, etc.как насчет _arraydata__ из класса netcdf_variable, http://scipy.org/svn/scipy/tru...> assert t1.do==t2.doВы просто применили операцию сравнения. Тjчно так же я мог бы завести 2 отдельных массива, заполнить их единицами, сравнить и сказать что они занимают одно и то же место в памяти.Советую вам в вашем примере вместо assert t1.do==t2.do выполнить assert t1.do is t2.do

>> то, что размер объекта в памяти зависит от размера исходного кода? > правильно ли я понял, что вы утверждаете, что не зависит? грубо говоря, размер объекта зависит от размера атрибутов (переменных экземпляра и методов), а не от количества строк в методах. последнее может влиять на размер байткода (pyc-файлы). по поводу отдельных экземпляров функций, которые вы не хотите создавать. объекты одного и того же класса не содержат разные «экземпляры» одной функции. предполагаю, что они просто ссылаются на один и тот же участок байткода, который был скомпилирован из исходного кода функции. class Test (object): def do (self): passt1 = Test () t2 = Test () assert t1.do==t2.do> не понял, чем пример со словарем не нравится? почему не нравится? и второй пример нравится, только это не то, о чем вы говорите. в указанных вами примерах используются встроенные функции, написанные разработчиками питона на С, а у вас — функции, написанные вами на питоне:) я так понимаю, ваши колеги просто попросили вас придерживаться определенного стиля именований методов, который идет в разрез с pep8., а про оптимизацию памяти вы сами додумали:)

строки указывать долго, можно просто по ctrl-f «__» походить, там хватает.

Да, примеров там хватает, и ни один из них ничего общего с betterThan не имеет — __pow__, __mul__, __retr__, __str__, etc.

> а чем вы говоритену, вообще-то, обычно ртом =) > то, что размер объекта в памяти зависит от размера исходного кода? правильно ли я понял, что вы утверждаете, что не зависит? не понял, чем пример со словарем не нравится? ну хорошо, этот вам подойдет? http://scipy.org/svn/numpy/tru...строки указывать долго, можно просто по ctrl-f «__» походить, там хватает.

Dmitrey, я все равно не могу понять, а чем вы говорите. пример с dict понятен — простой update словаря и ничего общего с вашим случаем не имеет. что вы имеете ввиду под копированием тела функции в каждый создаваемый объект? то, что размер объекта в памяти зависит от размера исходного кода?

> Это меня попросили делать авторы scipy, они сами это часто используют, см например> http://scipy.org/svn/scipy/tru..., line 28: > self.dict.update (options) Что-то вы напутали. dict же не авторы scipy придумали... В отличие от ваших betterThan

лично я пользуюсь ими для того, чтобы избежать копирования тела функции в каждый создаваемый объект.Это меня попросили делать авторы scipy, они сами это часто используют, см напримерhttp://scipy.org/svn/scipy/tru..., line 28: self.dict.update (options)

> по-видимому, вам стоит почитать в документации питона, чем отличаются атрибуты с двойным подчеркиванием от обычных.почитал: _doubleleading_and_trailing_underscore__: «magic» objects or attributes that live in user-controlled namespaces...Never invent such names; only use them as documented.что-то я не понимаю, о чем вы говорите. да, встроенные функции, выделяемые подчеркиваниями, оптимизированны., но betterThan то каким боком к этому относится? как подчеркивание связанно с оперативной памятью?

> И что потом, когда, например, в процессе разработки выясняется, что вот тот настоящий тулкит, который вы хотите использовать, с оригинальными алгоритмами, клинически отличается от того, на чём написали свой код вы? я не знаю, что именно имелось в виду под «клинически отличается» (и имелось ли в виду разные языки программирования), в любом случае прежде всего стоит смотреть что уже есть в scipy. Если этого не хватает — можно посмотреть на другие пакеты. В матлабе тоже далеко не все есть, иначе зачем тогда нужен http://www.mathworks.com/matla.../ и еще куча платных пакетов под него, например тот же TOMLAB.

Dmitrey, ну вот — опять тулкит. И для такой базовой вещи, как случайные распределения — тулкит. И, как всегда в таких случаях, этих тулкитов накапливается вагон и маленькая тележка, так как, как показывает история, желающих переписать и заоптимизировать классические алгоритмы среди студентов много. И что потом, когда, например, в процессе разработки выясняется, что вот тот настоящий тулкит, который вы хотите использовать, с оригинальными алгоритмами, клинически отличается от того, на чём написали свой код вы? У C++ — та же проблема. А в матпакетах типа Матлаба или R её нет, поскольку там матрицы и большинство стандартных математических операций загнали в базу. Кстати говоря, R на порядок гибче с размерностью, адресацией и применением итераторов, чем Matlab. Аналогов apply, по-моему, сейчас в Matlab нет (хотя могу и ошибаться). Зато в Matlab сейчас добавили распараллеливание задач в тулбоксе, вроде бы, что очень неплохо. По-моему, распараллеливания в R пока ещё нет. Хотя зря — при нынешних ценах на процессоры зачастую проще тупо параллелить, чем пытаться заниматься глубинной оптимизацией. Вот мне, например, интересно, в каких конкретных математических задачах в Python реально помогает ООП?

До речі є така штука, як LabVIEW, вона дуже добре підходить для RealTime, +не дуже важка у вивченні, +сумісна з Mat пакетами, +наочна, +швидкаОсновний мінус — ціна

Св. Бубукий, для собственных значений естьhttp://mdp-toolkit.sourceforge...кстати недавно его добавили в scipy.

Св. Бубукий, +500 ваш комментарий и статью нужно поменять местами

> 2Dmitrey: что это за загадочное шаманство с someFunc, someFunc и оперативной памятью? Cколько памяти вы таким образом «экономите» и как вы убедились, что использовать 2 функции вместо одной лучше? по-видимому, вам стоит почитать в документации питона, чем отличаются атрибуты с двойным подчеркиванием от обычных. > framework и library — это разные вещи. AMLP, GAMS, TOMLAB, AIIMS, LINGO — это никак не library, то же про OpenOpt.framework — это конструктор (например, гуишный фреймворк), library — готовое решение (например, библиотека готовых алгоритмов). что я могу построить на базе OpenOpt? ну уже хотя бы нелинейные функции из агрегатов, см http://openopt.org/oofun > на с/с++ большое количество других frameworks, там у пользователей есть выбор, в питоне же намного меньшечто мешает юзать плюсовые библиотеки из питона? 1) сложность 2) возможность легко понимать код и (при надобности) его модифицировать (вносить улучшения в исходники) > как вы предлагаете мне писать OpenOpt без использования классов? (чтобы сохранялся текущий синтаксис p=NLP (...) (или конструктор какого-то другого класса), затем вызов p.solve (), p.manage () и т.д.)? > например так: solve (p), manage (p), где р не объект NLP, а парамеры, которые вы передаете в NLP (...).Во-первых, я же спрашивал «чтобы сохранялся текущий синтаксис». Во-вторых, таких параметров там несколько десятков, вы предлагаете пользователям писать их в одну строку? > у меня к сожаленью гугл не работает — находит только вашу рекламу вашего «фреймворка»: (это легко лечится — добавьте в строку поиска «-openopt», или см мою вторую ссылку.> вместо того, что бы доказывать свою правоту, лучше прислушайтесь к критике, так как не только в НТПО люди знают питон...я не спорю, что на этом сайте полно людей, которые знают питон намного лучше меня. Но статья написана в первую очередь для тех, кто ВООБЩЕ НЕ ЗНАЕТ, что это такое и что его можно использовать в научно-тех. целях. Кроме того, по коментам непонятно, что здешние читатели собирались увидеть в этой статье? Может, копи-паст из python/numpy/scipy cookbooks? Лично я в первую очередь ориентировался на преподавателей информатики в школах/вузах, на их студентов, на научно-технических сотрудников.

Хочу вставить свои пять копеек. Заранее предупреждаю, что про Python до этого я не слышал, с Python не работал и в основном меня интересует, могу ли его использовать я. Лично мой опыт состоит в том, что в задаче «разработка научно-технического ПО» может означать несколько задач. Задача № 1 — реализация коммерческого кода в составе какого-либо продукта. Задача № 2 — реализация кода «для всех» для популяризации своих разработок. Задача № 3 — собственно говоря, разработка своих математических методов. В моём случае, это в большей степени означает № 3 для № 1, но имплементировать, в большинстве случаев, это всё же не мне. Если я буду говорить из своей практики, то основными проблемами в собственно разработке является: а) операции с данными б) реализация стандартных алгоритмов. в) реализация пользовательских интерфейсовг) сложность внесения изменений в код Если мы говорим про работу с данными, то, по крайней мере, на этапе прототипирования ситуация «а мы будем брать из не из этой базы данных, а из того файла, и ещё удалим вон те строки, а этот параметр возьмём из другого места, и так много раз» является достаточно стандартной. Традиционно любые математические пакеты и «быстрые» пакеты с массой библиотек типа С++ с этой задачей справляются довольно плохо. Лично мне это удобнее написать на Excel — в первую очередь потому, что your results are only as good as your data, во вторую — из-за того, что там легче находить ошибки и проводить аудит, в третью — всё-таки, ситуация при которых проблемы со скоростью начинаются из-за ввода/вывода данных — она не очень типична конкретно для прототипирования, или, опять же, она может решаться скорее специализированными пакетами типа того же SAS, нежели Python. Впрочем, похоже, что Python имеет ряд преимуществ при работе с мультимедийными файлами, но эта область лежит мне моей специализации, и её я обсуждать не берусь. Стандартные алгоритмы, и чисто математический код, реализованы в математических пакетах достаточно хорошо. В первую очередь из-за того, что в них обычно лежат достаточно сложные функции, которые, с одной стороны, являются стандартными, с другой — геморройными в реализации. Плюс при написании своего кода с массой циклов очень не хочется попасть в ситуацию, когда из-за пары простых изменений в формуле матричного умножения или замены метода обращения матрицы (ситуации вполне стандартные и житейские) нужно переписывать всё с ноля. Поэтому, в сложности внесения изменений в код, с моей точки зрения, опять-таки лидируют матпакеты. К тому же, хочется ещё сказать, что по коду довольно заметно качество среды разработки: ИМХО, корявые названия переменных и короткие функции свидетельствуют о довольно плохих средах, где информативностью названия жертвуют ради возможности его запомнить. Если говорить про интерфейсы ввода, то, с моей точки зрения, конкретно для математики и для прототипирования сложно придумать что-то лучше Excel. Если говорить про вывод — то мне как раз было бы интересно увидеть сравнение, насколько сложно что-то сделать в Matlab или Python (поскольку, похоже, графическая часть у Python довольно неплохая). Но автор этого не сделал. Так вот, что из этого следует: в моей практике, чаще всего компилированный код встречается в виде эдаких быстрых откомпилированных кусков, которым скормили чётко предсказуемый вход, которые потом его пережёвывают (обычно это задачи наподобие численного интегрирования, поиска оптимального решения (да и то не всегда) и как раз стохастической симуляции), которым скармливают набор параметров и от которых собирают результат собственно матпакеты или другие среды разработки. Поэтому для меня, например, важным параметром являются такие вещи, как, скажем, сложность передачи коду массивов или стандартизация классов. Честно говоря, довольно многие библиотеки страдают именно тем, что их довольно тяжело с чем-либо связать (особенно, я бы сказал, это касается низкоуровневых языков типа С). У пакетов типа того же R огромным достоинством является то, что как раз этот вопрос проработан достаточно неплохо. Что с этим у Python? Насколько легко код на нём связать с чем-то, отличным от C++? Ещё одно замечание: с моей точки зрения, я бы не отнёс Python к числу настолько интуитивно понятных языков, как Matlab или R. Всё-таки он более сложный, причём заметно более сложный. При этом кусками стандартного матлабовского функционала он не обладает. Собственно говоря, понять код автора я не смог. Найти в стандартных библиотеках функции для нахождения собственных значений — тоже. С моей точки зрения, Python в этом плане напоминает достаточно специализированный и ни в коем случае не универсальный математический пакет. Подходит ли он для разработки ПО? Не уверен, но автор на этот вопрос не отвечает (я бы сказал, что скорее нет, чем да). Может ли он заменить Matlab? Судя по всему, это зависит от задач. В моих задачах — вряд ли. В задачах автора — я не знаю, какие у него задачи, вместо этого статья льёт много воды по поводу лицензии и обычного для сторонников свободного ПО переливания из пустого в порожнее, что будующее — за некоммерческими проектами. Возможно, за ними будующее, но почему и для чего я должен использовать Python? Поэтому мой основной вопрос: для каких конкретно задач автор хочет использовать именно Python, почему и какие конкретные преимущества это ему даёт? Что он собирается сделать с кодом и для кого и для чего он его пишет? И, что самое главное: почему так же должны поступать и другие? На эти два вопроса статья ответа, в общем-то, не даёт. Отдельный камень хочется швырнуть в огород автора из-за «стохастической» направленности R. Это просто ошибка по Фрейду какая-то! В настоящий момент, по сути, R является де-факто академическим стандартом в статистике, поэтому при собственно говоря статистических проблемах тот же Matlab именно что курит в сторонке. Функционал у них в общем-то примерно одинаковый. Я бы сказал, что на сегодняшний день основными недостатками R является в основном неудобный интерфейс и передача данных, плюс, как всегда, стандарты, применимые в каждом из научных разделов. Впрочем, оговорюсь, что моё мнение — это мнение человека, которому практически не приходилось работать с данными в реальном времени. Преимущества и недостатки языков на данных реального времени я описывать не берусь, но подозреваю, что там будет всё совсем по-другому. Собственно говоря, судя по моему беглому взгляду на стандартные библиотеки я бы скорее отметил работу с сокетами и бинарниками у Python, что, вполне возможно. объясняет его популярность в среде machine learning. Однако, по-моему, автору не мешало бы всё-таки про это сказать и отметить в качестве преимуществ. А так — статья очень слабенькая.

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

2Dmitrey: что это за загадочное шаманство с someFunc, someFunc и оперативной памятью? Cколько памяти вы таким образом «экономите» и как вы убедились, что использовать 2 функции вместо одной лучше? Преждевременная оптимизация — зло:) > framework и library — это разные вещи. AMLP, GAMS, TOMLAB, AIIMS, LINGO — это никак не library, то же про OpenOpt.framework — это конструктор (например, гуишный фреймворк), library — готовое решение (например, библиотека готовых алгоритмов). что я могу построить на базе OpenOpt? хотя все это словоблудие, но интересно, в чем вы видите отличие.> на с/с++ большое количество других frameworks, там у пользователей есть выбор, в питоне же намного меньшечто мешает юзать плюсовые библиотеки из питона? > как вы предлагаете мне писать OpenOpt без использования классов? (чтобы сохранялся текущий синтаксис p=NLP (...) (или конструктор какого-то другого класса), затем вызов p.solve (), p.manage () и т.д.)? например так: solve (p), manage (p), где р не объект NLP, а парамеры, которые вы передаете в NLP (...).по поводу nonLinFuncs — выше уже писали, почему фигово лепить кучу классов. функции, манипулирующие объектом класса NonLinProblem, вынесены в отдельный класс, от которого класс NonLinProblem наследуется. здесь много странных моментов, например, nonLinFuncs работает с данными наследника!, nonLinFuncs нельзя использовать вместо NonLinProblem и т.д. если уж ваши менторы не разрешают вам писать функции, не члены класса, потому что поламается ооп, то используйте хотя бы агрегацию вместо наследования.> советую посмотреть в google «numerical optimization framework» (желательно с кавычками) у меня к сожаленью гугл не работает — находит только вашу рекламу вашего «фреймворка»: (вместо того, что бы доказывать свою правоту, лучше прислушайтесь к критике, так как не только в НТПО люди знают питон...

да, ygrek, я считаю, что не обязан тратить время на аргументацию про плохую, на мой взгляд, семантику F#. Как говорится, на каждый чих не наздравствуешься. Если вы действительно считаете ее лучшей чем Python, Ruby etc — ну так и пользуйтесь себе на здоровье, тут же никто не против.

> про недостатки — это мое субъективное мнение. Тему раскрывать не буду, чтобы не ввязываться в очередной holy war.Мило. Т.е. выдать на гора своё «мнение» вы готовы, а аргументировать — нет? Тогда это не мнение, а пустое место.> кстати, про QPL (под которой лицензирован компилятор) немало плохого говорится тут> http://en.wikipedia.org/wiki/Q...Ух ты, а вы уже компилятор патчить собрались?

вообще-то сокращение LGPL обычно расшифровывается как Lesser GPL, а не Library GPL (это Library — предшественник Lesser) и все-же своих ограничений у нее хватает.http://www.gnu.org/licenses/ol...кстати, про QPL (под которой лицензирован компилятор) немало плохого говорится тутhttp://en.wikipedia.org/wiki/Q...

> The Library is distributed under the terms of the GNU Library General Public License version 2> она тоже имеет copyleft:) Разницу между утверждениями “OCaml — GPL” и “OCaml standard Library — LGPL” чувствуете? Как это может ограничивать — то что stdlib под LGPL? LGPL не copyleft, в том смысле что линковка с stdlib не обязывает открывать свой код.

Люди добрі. Всі хто сумнівається, що Пайтон+Numpy одне з найкращих засобівдля number crunching, поставте собі IPython i Numpy і поекспериментуйте.Я от думаю, що Lua, VB і С# до зручності і гнучкості Пайтон+Numpy ще далеко. І справа тут не в «множественном наследовании», а саме в Numpy і Scipy, ну і ще в тому, що такий динозавр як Fortran дуже легко підключається до пайтона, що дозволяє не переписувати всі здобутки останніх 50 років.Хоча може ви знаєте якісь спеціалізовані «пакети» для цих мов, які не поступаютьсяNumpy?

ygrekhttp://caml.inria.fr/ocaml/lic..."The Library is distributed under the terms of the GNU Library General Public License version 2"она тоже имеет copyleftпро недостатки — это мое субъективное мнение. Тему раскрывать не буду, чтобы не ввязываться в очередной holy war.

Про Lua — ну смотрел я его когда-то (когда у него был резкий рывок вверх в TIOBE). Пристально я не приглядывался, но мне он показался просто YAPL — ом, таким же как Cobra или groovy. Кроме того, опять же очень важно колическтво софта под него. Сейчас кстати я вижу, что он заметно упал http://www.tiobe.com/index.php.... Я вполне могу поверить, что что-то в нем сделано получше vs Python, так же как и в других язіках — Cobra, Ruby, groovy, создававшихся после Python и соответственно принявших во внимание накопленный опыт его недостатков. Но про научное-техническое программирование — там речи и близко нет о таких библиотеках как numpy/scipy и тп, точнее есть конечно, но они никакого сравнения не выдерживают (находятся в очень начальном состоянии, и вряд ли когда-то догонят). Просто кто будет переписывать все эти мегатонны кода и ради чего? Переписывать с фортрана на питон (или с С, MATLAB) по крайней мере были причины — отсутствие RAD-свойств, проблемы с лицензией, отсутствие передачи по ссылке в матлабе и тп. почему именно OPT++, и как тут можно сравнивать? кол-во пользователей мне даже своих неизвесно, не говоря уже про другие. Кроме того, на с/с++ большое количество других frameworks, там у пользователей есть выбор, в питоне же намного меньше (cvxopt, openopt, nlpy).Фраза про Перл — не я придумал, но мнение ее автора я полностью разделяю. Хотя не думаю, что понимать его обязательно надо так буквально, с секундомером.betterThan — вот я и говорю, что не хочу тратить лишнюю оперативную память на тело какой-либо функции в каждом объекте Point, а двойное подчеркивание делает синтаксис уродливым. Поэтому в scipy такой подход практикуется очень широко (т.е. заводят 2 функции — someFunc и someFunc), и во время GSoC именно такой подход требовали применять мои mentors. framework и library — это разные вещи. AMLP, GAMS, TOMLAB, AIIMS, LINGO — это никак не library, то же про OpenOpt. У frameworks куча своих функций, возможностей и т.п., а также подключения к внешним солверам. Я у себя на сайте слово library вообще нигде не употребляю.> Ужасное, должно быть, было время.я по этому поводу могу сказать, что когда в МАТЛАБ-е только-только внедрили визуальную систему предупреждений/ошибок (в версии 7.0), когда я открывал чужие пакеты, написанные под 6.5, там только одних неиспользуемых переменных было по десятку в файлах (ну например когда я смотрел http://www.mathworks.com/matla..., сейчас, наверняка, они уже подчистили). И это при том, что его разрабатывала опытная команда программистов, и на ряде тестов он показывал куда лучшие результаты чем коммерческие солверы, например тот же fmincon из MATLAB Optimization toolbox.BTW, В.С., а ты до сих пор еще в КомСет?

2Сергей Волошин, вопреки статистике VB.NET весьма распространен. К тому же он так похож на C#, что разницы то почти и нет.А по поводу статьи — хоть я и очень люблю Python, но думаю, что этот язык больше подойдёт для прототипирования научно-направленных приложений. Естественно, так как из прототипов вырастает не так много реальных приложений, то это нормально — Python позволяет разработать что-то нереально быстро, при этом потом всегда можно при надобности оптимизировать.

С каких пор это OCaml — GPL? Про семантические недостатки камля очень интересно почитать — раскроете тему?

2Сергей ВолошинПроблема була з ВБА (доводиться час від часу писати макроси) Так, VB.Net з VS2008 сильно схожа на C#

2dol: Тут: http://www.microsoft.com/express/product/Visual Basic описується як"Productivity that is ideal for first time or casual Windows programming."Мені суб’єктивно здається, що VB (.NET) останнім часом (за останні 5 років) трохи здав свої позиції на користь C#.

ПІдтримаю lunatic, погано коли в мові використовуються символи яких ти не бачиш:) (я про Tab), людям, які вивчали інші мови важко виділяти групу операторів відступами (краще вже begin...end;, {...}, чи щось подібне), так, є правила хорошого тону (чи як вони там називаються), однак багатьом, особливо початківцям важливий тільки результат, а не читабельність коду... Ще на рахунок необовязковозті оголошення типу змінних, колись більше години мучився із здавалося б хорошим кодом на ВБ, в кінці вийшло, що в імені якоїсь із змінних допустив синтаксичну помилку...:) Взагалі то, майбутне за MSVS (C#, VB, F#...). А для розрахунків і Паскаль підійде, тим більше що він входить до шкільної програми, та й в універах його вчать...

mishok13 я так понимаю код ты в pylint смотрел угадал? (по крайней мере не в треке). Ну, тогда тут много ума не надо.

Когда мы с mishok13 обсуждали код, то смотрели как раз в траке. Делать ото нефиг — качать его весь, pylint натравливать... И так всё невооружённым глазом видно.

что смешного в betterThan? Я не хочу создавать отдельный экземпляр функции в каждом объекте класса

Ээээ? Зачем их создавать в каждом объекте?

Кстати, я очень долгое время писал в IDE без pylint и даже каких-либо предупреждений подсветками.

Ужасное, должно быть, было время.

>> особенно это актуально для Perl, где написанный код понимает только его автор, и то обычно не дольше 15 минутХватит на Перл то гнать. Если ты Перл видел 2 раза в жизни и чего-то в синтаксисе не понимаешь, то не надо писать что все остальные не понимают своих и чужих исходников. Не хочу разводить тут холивар, но тебе нужно к относится к «не-Питонам» и, соответственно, к людям которые на этих «не-Питонах» пишут с бОльшим уважением.

да я ж не против что оно нужное, но судя по тому, что я увидел в коде, достаточно сырое, Дима, не дуйся, не будь бякой:) относительно советов посмотреть в google "library optimization methods"btw OPT++ vs OpenOpt, пока кто кого?

2 COTOHA;) Хорошо про наследование Стиви Едж написал:

For example, you may find a candidate who decides that a Vehicle class should be a subclass of ParkingGarage, since garages contain cars.

http://steve.yegge.googlepages...

Поважаю автора за його вибір Дійсно не легко вибрати інструменттим більше для наукових розрахунківЦікаво що автор думає про мову яку він тут не згадує, а саме LuaДійсно в багатьох випадках для визначеннянаскільки вдалою є та чи інша моваможна взяти її синтаксисНедарма автор згадує знаки долара і таке іншеТут якраз і видно хто є хтоВ пітоні не має знака долара, добре, тоді що з того якщо у мене в очах рябить від знака self або я мушу слідкувати за тим поставлений знак табуляціїї чи ні Якраз такі як здавалося б дрібниці і говорять про автора мовиТому останнім часом я не перестаю дивуватися Робертом ЄрусалимшіНастільки вдалою є його реалізація теж не строго типізованої мовиале, на мою думку, безперечно вдалішої за пітонСаме цікаве що якраздля математичних розрахунків Lua мені здається найбільше підходитьтому що поняття таблиці (матриці) є основним в цій мовіЗнову ж таки все геніальне — просте Я маю на увазі як автор Lua одним поняттям (таблиця) привів усі парадигми програмування до одного знаменника

2 Dmitrey

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

вот мне всегда были интересны ситуации, когда необходимо множественное наследование. теория гласит, что оно нужно, когда класс является одновременно представителем 2х (и более) сущьностей из предметной области. Действительно ли Задача одновременно является Матрицей, Остатком и ТекстовымВыыодом? скорее она включает эти сущьности...может для ДОУ стоило-бы написать статью по архитектуре OpenOpt’а?

2COTOHA: Обсуждение этой статьи напомнило обсуждение статьи "Программистские ошибки для чайников"P.S.Время от времени хочется как-то разделить комментарии к статье на 2 отдельных потока — комментарии о статье и/или обсуждении статьи и комментарии по теме статьи.

2 Dmitrey

половина коментариев — типичный say something syndrome.

не, просто то, что хорошо для профессоров-теоретиков, не подходит для программистов-практиков.я пока читал статью не мог отвязаться от такой картинки: пишите вы свой фреймворк, пишите на питоне, вам нравится..., но тут приходит время что-то сказать в универе, а там сидят профессора-академики и недоумевают: "какой-такой питон-шмитон? почему не старый добрый fortran? почему не СС++? почему не новая (ну по профессорским меркам новая) Java? почему на надёжный матлаб? "вот тут и рождается этот опус, который преследует 2 цели: 1. унизить конкурентов С++Яваматлаб — вскользь, чтоб не сильно обижать...2. выделить питон из кучи прочих buzzwords, хотя профессорам вообще-то уже пофигу — они всё равно ничего не понимают, но мало говорить нельзя, вот и приходится лить воду...вот и получается, что для основной категории читателей этого сайта вся статья "типичный say something syndrome"©

Tupitskiy Dmitriy, советую посмотреть в google “numerical optimization framework” (желательно с кавычками) или http://openopt.blogspot.com/20...

mishok13 я так понимаю код ты в pylint смотрел угадал? (по крайней мере не в треке). Ну, тогда тут много ума не надо.Где именно в коде OpenOpt ты предлагаешь мне использовать генераторы? К тому же, ими я не пользуюсь уже хотя бы потому, что в версии 2.3, в которой я начинал их не было (и которую программисты numpy поддерживали до сих пор, только несколько дней назад заговорили о сбросе). В требовании моих GSoC-mentorов (из scipy dev team) и в 2007, и в 2008 была совместимость с 2.3. Кстати, я очень долгое время писал в IDE без pylint и даже каких-либо предупреждений подсветками.PEP-8 и тп — когда я начинал несколько лет назад, у меня было намного меньше опыта, а переписывать столько кода сейчас некогда, работает — и ладно.http://trac.openopt.org/openop...у меня эта функция используется еще и в конструкторе MILP, а не только LP. Писал я ее 2 года назад, сейчас написал бы по-другому, но переписывать все неохота.про rjust — что тут такого? можно конечно использовать ’’.rjust.что смешного в betterThan? Я не хочу создавать отдельный экземпляр функции в каждом объекте класса (кстати объекты Point создаются/удаляются сотнями на пике самых интенсивных вычислений, и это в глубоко вложенных циклах, так что еще на несколько порядков надо умножить).setDefaultIterFuncs.py — это у меня же в OpenOpt и обрабатывается (в http://trac.openopt.org/openop...). См также http://trac.openopt.org/openop..., там написано зачем это надо (чтобы пользователю необязательно было в обязательном порядке для каждого своего istop придумывать текстовый msg).про EmptyClass — он используется в http://trac.openopt.org/openop...можно конечно же было и dict заводить, но мне точку писать быстрее чем [’’].> Если бы ты смотрел код, то такого бы не написал.я же говорю — смотрел! Ну не веришь — не верь, мне то что.> они писали без использования классов ради классовя тоже писал без использования классов ради классов. Я делал то что пообещал scipy devs сделать в моем GSoC-application.> Я уже бегу предлагать Р. Хеттингерууспехов!

ну за то что продвигает в МОН, за это я ему лично готов крепко пожать лапу, это действительно подвиг:) порад ужо и без меня надавали. Да думаю автор и сам вкурсе своих тараканов в коде. Вот реализует все тудушки, кааак отрефакторит все, и будет новый шайни релиз yet another library %) кстати, там еще состояние глубокой альфы? или это я ошибаюсь? P.S. по большему счету если разрабатывает один человек и число реальных пользователей около 10ка и продукт выполняет свои задачи, то неважно как оно написано, лишь бы автору эта манера подходила:)

> ребяты, а давайте не будем учить автора статьи, пусть сам учиться.... по своим статьям:) А чому ні? Автор заслуговує поваги, оскільки розробляє українське вільне ПЗ.Та ще й намагається його просувати у МОН.Отже, пропоную перестати «класти купки» в каментах, а всім дружнонадавати автору корисних порад:) Tupitskiy Dmitriy, це особливо вас стосується;)

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

Посмотрел код....Надеюсь, что свои навыки программирования ты будешь использовать исключительно в научных целях.Ибо: 1. PEP-82. Полное игнорирование генераторов и list comprehension3. God objects all over the place4. За простой «except: » по рукам надо бить. Хотя бы «except Exception: », блин.5. Old-style classes. Ну, я понимаю, что у тебя планах поддержка питона версии < 2.2.:) 6. Злоупотребление name manglingЕще много чего другого, но у меня глаза начинают от этого слезится. ИзвиняйИз клевых моментов: — http://trac.openopt.org/openop...В инициализаторе вызывается функция, которая добавляет аттрибуты к обьекту. Причем, у тебя паттерн такой, ибо почти в каждом классе в методе init вызывается функция. Очень обьектно-ориентировано, гыгы.- http://trac.openopt.org/openop...string module is deprecated- http://trac.openopt.org/openop...тут у меня случилась истерика — зачем ты метод betterThan создал, и его просто вызывать из метода betterThan? Чем они принципиально отличаются? Ну, кроме названия. (Это твой паттерн, ага?) — http://trac.openopt.org/openop...Все функции могут возвращать два принципиально разных типа обьектов — bool или tuple. Это одно из самых оригинальных решений, которые я когда-либо видел. Надо бы еще добавить if random.random () < 0.25: raise Exception для нечеткой логики.- http://trac.openopt.org/openop...?

как вы предлагаете мне писать OpenOpt без использования классов?

Авторы множества библиотек и приложений на питоне нервно икают — они писали без использования классов ради классов. Я уже бегу предлагать Р. Хеттингеру пересмотреть подход к itertools и functools и сделать всё классами с соответствующими методами. API будет следующим: f = BigFsckingObject (); f.ifilter (); f.imap (); и т.д. Можно будет грабить корованы.

> Посмотрите код стандартных библиотек питона.смотрел

Лукавишь, ай лукавишь... Если бы ты смотрел код, то такого бы не написал.

> использование классов и наследования только, потому что... ООП — фиговая идея.как вы предлагаете мне писать OpenOpt без использования классов? (чтобы сохранялся текущий синтаксис p=NLP (...) (или конструктор какого-то другого класса), затем вызов p.solve (), p.manage () и т.д.)? > Посмотрите код стандартных библиотек питона.смотрел> То, что у Вас называется nonLinFuncs яркий пример этому (объяснить?) слушаю

Dmitrey, использование классов и наследования только, потому что... ООП — фиговая идея. То, что у Вас называется nonLinFuncs яркий пример этому (объяснить?). Посмотрите код стандартных библиотек питона. Вообщем, я бы не стал выбирать python, руководствуюясь тем, что у него есть множественное наследование, а у ruby — нет (кстати, почитайте о примесях в руби).

"и мне сложно представить, как без него можно обойтись в некоторых частях кода, например здесь http://trac.openopt.org/openop..."да можно, чего уж там... это ж классическая задача по избавлению от множественного наследования:) не нужно из идиомы серебрянную пулю лепить и все станет проще.

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

2Dmitrey: Посмотрел Ваш код, так и не понял, зачем вообще там нужно наследование??? Для того, что бы использовать функцию не нужно создавать отдельный класс и потом наследоваться от него

mx, я пользуюсь отладчиком в Python (и достаточно интенсивно), о чем упомянул в заметке про Eric. Но в Python потребность в нем возникает намного реже чем в С/С++ и тп, особенно если рассматривать несложные программы из д/з школьников/студентов. Кроме того, чем мне нравится Eric — так это тем, что даже при выполнении (а не отладке в дебаггере) кода при возникновении ошибки он не сворачивает стек, можно сразу разобраться что и где произошло. Хотя и в каких-то других Python IDE это наверняка есть.Все кроссплатформенные проблемы языков С/С++ взяли на себя разработкики языка Python (и прилагающихся к нему С-шных модулей). А программисты Python с ними уже не сталкиваются. То же самое — для комента про Qt.

С/С++ не кроссплатформенные языки? А на чем написан Python? А на чем написана Java, которая кстати работает быстрее языка на котором написана.>> а пользоваться отладчиком многие не умеют (особенно школьники и студенты) Про отладчик это как? Найден метод разработки безошибочных программ! Язык Python не требует отладчика! В нем ведь нельзя ошибку сделать.Знаем мы эти языки, они просто смещают ошибки компиляции на время выполнения.

Я не могу отвечать за всех разработчиков НТПО, но в моем OpenOpt множественное наследование используется (и мне сложно представить, как без него можно обойтись в некоторых частях кода, например здесь http://trac.openopt.org/openop...).

ну хорошо, тезка, вот скажи отсутствие множественного наследования это действительно недостаток ЯП? с каких пор? Научно-техническое ПО правоверные кодеры теперь без множественного наследования не разрабатывают? А то что у сабжа поддержка МН урезанная это тоже теперь недоязык для НТПО? Мне думаеться, что если все спорные и необоснованные агрументы из статьи выкинуть, остануться ссылки и заимствования:)

половина коментариев — типичный say something syndrome.

> Возникает вопрос: и чо? Я считаю это весомым аргументом в доказательство того, что MATLAB и Fortran вытесняются другими ЯП. Кроме того, это подтверждают мои двухлетние наблюдения на TIOBE.> Так на руби или питон похож груви? Ибо я как-то не уловил связи между руби и питоном (ну, ключевое слово def, ага, да вот только семантика слишком различна). Можешь как-то обосновать схожесть питона и груви (HINT: сравни для начала руби и груви)? Я считаю, что приведенной мной ссылки из groovy FAQ достаточно.> Выучить любой ЯП можно, но результат будет в 99% случаев очень плачевным. Вне зависимости от ЯП.не понял идеи. Могу добавить, что для (приемлемого) изучения MATLAB мне хватило 3-дневного курса (оплаченного конторой), поэтому за 2 недели выучить Питон (на базовом уровне, конечно) проблем нет.от недостатков OCAML — семантических.> Остальные вопросы остались неотвеченнымиа что я должен отвечать на вопросы типа «есть прямые доказательства? » или «Ммм, правда? »? Распинаться что «да, правда» или как?

Дима, с тобой на ты буду общаться, ок?

Think of it as a Ruby or Python like language [...] allowing you the same powerful and concise coding syntax as Ruby or Pyton [...]

Так на руби или питон похож груви? Ибо я как-то не уловил связи между руби и питоном (ну, ключевое слово def, ага, да вот только семантика слишком различна). Можешь как-то обосновать схожесть питона и груви (HINT: сравни для начала руби и груви)?

Что касается Ruby, сам его автор говорил, что списал его с Перл и Питон (добавив свои улучшения).

Сам BDFL взял много чего из ABC, который в свою очередь, взял много из Basic. Ну, вывод же очевиден, да? Basic >> Python, гыгы. Чувствуется, что руби ты даже не пробовал, по-настоящему.

Стоит также заметить, что google-тренды для MATLAB и Fortran очень сильно убывающие

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

Статья понравилась, автору спасибо! =) Кстати есть такая штука http://www.myhdl.org/doku.php

MyHDL is an open source Python package that lets you go from Python to silicon. With MyHDL, you can use Python as a hardware description and verification language.

Пишите программу на Питоне, потом немного магии, отсылаете результат друзьям-китайцам, и через 3−6 месяцев у вас есть ваша программа в виде кремниевого чипа! =))

не статья, а позор украинской науки: (низкоуровневый язык C++ не позволяют RAD, а Borland и не знал 10 лет выпуская RAD для такого плана ЯПну и конечно же нафиг наукоемким вычислениям выполняться быстро, ведь у нас же плантации серверов, да такие, что гугль аж из зависти зеленеет. про кросс-платформенность, мда... хорошо, что бездари в trolltech этого не знали и подарили миру QT, на которой ой как много всего написаноа после «недостатка» «необходимость заканчивать каждую строку кода символом; » — автору в детский сад, доучивать азы

Стоит также заметить, что google-тренды для MATLAB и Fortran очень сильно убывающиеhttp://www.google.com/trends

> Ну, Вы в курсе, что Groovy бегает на JVM, а Cobra на.NET/Mono? Да, я в курсе (интересно, а что такого в моей статье заставило Вас в этом усомниться)?

Это значит, что и для Groovy, и для Cobra существует немалое количество библиотек.

> Ну, Вы в курсе, что Groovy бегает на JVM, а Cobra на.NET/Mono? Да, я в курсе (интересно, а что такого в моей статье заставило Вас в этом усомниться)? > Ну и, главное, что Groovy уж никак не клон питона.Читаем http://groovy.codehaus.org/faq...What is Groovy? [...] Think of it as a Ruby or Python like language [...] allowing you the same powerful and concise coding syntax as Ruby or Pyton [...] Что касается Ruby, сам его автор говорил, что списал его с Перл и Питон (добавив свои улучшения). «Широко библиотеки» — опечатка, имелось в виду «широко распространенные». Я пока не знаю людей из ИК НАНУ, которые о них не слышали.

В Emacs/Xemacs я работал полтора года, считаю это устаревшим (не говоря уже про vim) и неподходящим для разработки ПО, тем более научного. Лисп я тоже видел. Про транслятор MATLAB в С читал сообщение пару лет назад, что какая-то там фирма его сделала и показала журналистам его безошибочную работу на исходниках в несколько тысяч строк. Но я не знал, что Mathworks теперь распространяет его вместе с MATLAB (и, по-видимому, позначительно меньшей цене, чем та, которая была в сообщении, что-то около 30000$). Или это не тот продукт, а улучшенный транслятор Mathworks? В любом случае интересно, как он справляется со всеми этими assignin, evalin, элементами ООП. Цитата из вашей ссылки: «отметим, что функции некоторых пакетов расширений (toolboxes) MATLAB недоступны для компилятора MATLAB». Я так понимаю, что и с кодами пользователя тогда могут быть проблемы. Дальше я читаю уже про знакомые файлы ctf и необходимость устанавливать MCR (260 Мб на диске) — ну что же, для меня это давно уже пройденный этап. Я не считаю это компиляцией в native code. С таким же успехом (а может, и еще большим) я могу предъявить вам shed-skin — python to c++ compiler. http://shed-skin.blogspot.com/. Жаль, забыл упомянуть его в статье.Про передачу аргументов копированием — вы вообще сами-то пользуетесь assignin, evalin?! Я пробовал и результат меня не впечатлил, слишком сложный получается код, самому надо вспоминать, что и как работает, а что уж говорить про другого программиста, которому когда-то придется вносить изменения в ваш код? Пользоваться global полегче, но во всех документациях это не советуют (не только к МАТЛАБу), т.к. это очень ненадежно (как впрочем и делает код непрозрачным, и нестабильным, особенно если потребуется запускать каким-то способом распараллеленный код). Также, особенно в больших проектах, где работает много программистов, возможно случайное использование одинаковых имен в global, которое потом сложно отследить даже в отладчике.

Практически все неверно. За науку обидно

і чим ж ліцензія ГПЛ в Octave/scilab/axiom/maxima вам недовподоби? тим що заставляє відкривати свої напрацювання?

Сам автор между прочим не поленился поставить точку с запятой после каждого пункта: Р)

Это я как «CSS программист:) » не поленился.

Видно кто-то очень любит Питон. Язык, конечно возможно и неплохой, но само сравнение матпакетов с языками програмирования доставляет немало хорошего настроения. В этом списке еще не хватает: Делфи, Ассемблер, Фотошоп, Ексель ит.п... и незабудьте объяснить почему Python их лучше! "Кто так пишет?! «© (или «почему я так люблю матлаб») Отметим также, что даже несомненный лидер из матпакетов — MATLAB — также обладает рядом недостатков: необходимость заканчивать каждую строку кода символом «; »; отсутствие компилятора в машинный код; неудобная стыковка с другими языками программирования (С, Fortran) посредством mex- функций; неудобная обработка строк и ряда других типов, в том числе классов ООП; передача аргументов копированием; Первым пунктом, главный минус Матлаба! 1) необходимость заканчивать каждую строку кода символом «; »; Очень болезненный минус, для автора. Видел бы он Лисп... (Сам автор между прочим не поленился поставить точку с запятой после каждого пункта: Р) 2) отсутствие компилятора в машинный код; 3) неудобная стыковка с другими языками программирования (С, Fortran) посредством mex- функций; Есть в Матлабе такая штука, как компилятор, который позволяет, компилировать в машинный код. Также Матлаб билдит компоненты, которые могут подключаться к.Net, Java, VBA.Чуть подробнее можно прочитать здесьКомпилятор Матлаба может билдить, как из mex-файлов, так и из m-файлов4) неудобная обработка строк и ряда других типов, в том числе классов ООП; про это конечно ничего не могу сказать, есть немножко5) передача аргументов копированием; это конечно есть, ноЦитата Для передачи по ссылке можно применить переменные global, дескрипторы функций @, механизмы assignin, evalin.©Консультационый центр матлаба Единственный минус матлаба, с которым я согласен: он платный!

Понравилось, что в недостатки матлаба внесено вот это: > необходимость заканчивать каждую строку кода символом «; »; Странно, что автора статьи не напрягала необходимость заканчивать каждое предложение точкой...

Грамматика, аргх!

Прежде всего, низкоуровневые языки, такие как С, C++, Fortran, Assembler

Смешались в кучу люди, кони...

Одной из составляющих RAD-свойств Python является отсутствие строгой типизации

Имелось в виду «статической», да? В питоне типизация строгая, но динамическая.

Выучить Python несложно даже школьнику за пару недель, чего нельзя сказать про C/С++, Fortran, Ocaml, Erlang.

Выучить любой ЯП можно, но результат будет в 99% случаев очень плачевным. Вне зависимости от ЯП.

тогда как свободное ПО без copyleft постепенно вытесняет содержащее copyleft

И у Вас, несомненно, есть тому прямые доказательства. Да даже если и нету, мы поверим Вашему авторитетному мнению.:)

Типичный пример — широко библиотеки BLAS и LAPACK.

I just accidentally a whole coca-cola bottle.

Ruby —... отсутствие множественного наследования, неопределенность в выборе наиболее быстрого подхода к написанию участков кода.

Как это мешает в научно-технических приложениях для меня остается загадкой.

Groovy, Cobra (не путать с CORBA) и другие клоны Python — в первую очередь небольшое кол-во написанного для них ПО... язык без батареек сейчас никому не нужен.

Ну, Вы в курсе, что Groovy бегает на JVM, а Cobra на.NET/Mono? Ну и, главное, что Groovy уж никак не клон питона.

F# не полностью избавился от недостатков OCAML

КАКИХ? Лицензии и сложности изучения?

конкурирующегос Python языка С#

Ммм, правда?

Основные среды разработки для Python

Этот раздел поразил меня отсутствием упоминаний об Emacs или vim

Возможно, в будущем Python (так же как и С, Fortran, MATLAB) будет вытеснен Fortress

Сколько лет Fortran? 51. А C? 29. А Fortress? 1. Вот через 20−30 лет может быть (если Sun к этому времени не обанкротится, а это вполне возможно) Fortress будет составлять этим ЯП конкуренцию.Статья полна очевидных ошибок, buzz-word’ов и прочей шелухи из интернетов. Я, как человек, который пишет на Python и C, разбавляя это в последнее время OCaml, получил массу позитивных эмоций, читаю данную статью.:)

Феноменально бездарная статья, не только не раскрывает топик, а еще и вводит в тотальные заблуждения.Большинство изложенных тезисов либо не верны, либо искажены с не детерминированным вектором искажения.P.S.: Автор, учи англйский. «they are not recommended unless using Forum is possible»: здесь должно быть ’impossible’, вестимо."+ I have MATLAB sertificate«:, а тут ’certicifate’.P.P. S: Твое имя правильно транслитерируется «Dmitry», если только тебя не зовут «Дмитрей»...P.P. P.S: Цитаты из http://openopt.org/Dmitrey

> каких-нибуть школьников из Индии или КитаяДа автор же расист. Скинхед. х.н.с., млин.

м.н.с. — это читается как младший научный сотрудник? и в правду после распада СССР весь ученый потенциал уехал за границу.Статья явно человека, который не занимается этим всем практично, поэтому не чувствует.

На всякий случай приведу еще ссылку на обсуждение на Хабре: http://habrahabr.ru/blogs/python/51715/#comments

Я сам программирую на Питоне, но статья эта... Больше на антирекламу похоже.Ну и видно, что это не статья, а именно презентация — ничего по сути не сказано, ход «повествования» перепрыгивает с места на место, много ошибок, опечаток, и просто неточностей.

Шановні читачі, вибачайте, але наразі я не можу попрацювати додатком до гугла, в мене купа інших справ.Щодо F# — звичайно, мався на увазі його автор.

>> В половине F# FAQ автор неубедительно пытается откреститься от Microsoft и возможных лицензионных проблем.А шо за FAQ та що за автор? >> ◦IronPython — имплементация Python под Microsoft.NET. Имеет свой контингент пользователей, но в первую очередь Microsoft занята продвижением конкурирующегос Python языка С#.Гм, а це ви звідки витягли?

Подписаться на комментарии