пятница, 30 августа 2013 г.

Почитал про Python. Вот ни разу не впечатлён (положа руку на сердце - ОДИН раз впечатлён)

Почитал про Python. В частности вот это - http://rus-linux.net/MyLDP/BOOKS/python.pdf

Вот ни разу не впечатлён.

(положа руку на сердце - ОДИН раз впечатлён, про "ссылки" на объекты, сам - ДОЛГО над этим думал, но так и не "вкурил" НУЖНОСТЬ. А теперь - "вкурил")

Всё там же "стековая машина" со "словарями". Не  более того. А "синтаксис" без ОПЗ. Ну "синтаксис". На вкус и цвет.

Использовать как DSL - не то чтобы прям уж ИДЕАЛЬНОЕ решение. На мой вкус - тоже вполне себе "криптован".

В общем это моё частное мнение. "Уговаривать" меня в обратном - не  стоит :-)

Что касается "словарей" и построения на их основе "классов" - ну "мой FORTH" ровно так и устроен. Только он компилируемый и контроллирующий типы.

Что касается интроспекции - она также - есть. Как и множественное наследование, как и переопределение "методов" что мета-классов, что их экземпляров.

Лямбды - конечно тоже есть. Списки и словари - конечно тоже.

Параллельного присваивания - нету. Но в общем - понятно как его сделать, если сильно хочется. Собственно через "списки" о чём честно и написано в документации к Python.

Unicode - я тоже конечно же умею обрабатывать.

Ну и на закуску:
def __init__(self):
self.__dict__[self.__vdict_name] = {}
def __getattr__(self, name):
return self.__vdict[name]
def __setattr__(self, name, value):
self.__vdict[name] = value

--  подобное не кажется мне прям ИДЕАЛЬНЫМ для DSL.

По-моему вот это - http://18delphi.blogspot.com/2013/07/blog-post_196.html  - сильно веселее.

P.S. Хотя про интеграцию Python и Delphi - был бы рад, что-нибудь стоящее почитать.

P.P.S. Дали ссылку - http://dondublon.livejournal.com/68416.html

"После работы скрипта все объекты типа TPyObject уничтожаюся сами. Если объект представлял собой обертку для вашего рабочего объекта и держал на него ссылку, уничтожение ссылки коректно не делается и вы получите утечки памяти. Я достаточно долго ломал голову, как разрулить этот вопрос, в итоге получил рецепт: сделать у каждого такого TPyObject метод очистки ссылок, вызвать его вручную после работы скрипта, причем - это важно - этот метод должен быть не в деструкторе! Может, есть способ элегантнее, но я его не знаю."

Дьявол то - он как обычно - в деталях :-)

P.P.P.S. Похоже меня не до конца правильно поняли. Концепция ВНУТРЕННЕГО устройства Python - мне вполне БЛИЗКА и понятна. Потому и не впечатлён наверное. Может быть ждал "откровения", а оно - не случилось. А что до "синтаксиса" - тут и обсуждать нечего. Синтаксисы - они разные бывают. На вкус и цвет. Меня вот например SmallTalk - несколько "шокирует". Но это - ровным счётом ничего не значит. ОПЗ - я не то чтобы считаю сильной стороной. Нет конечно. Арифметика в ОПЗ - конечно ужасна. Но в целом - только арифметика.

P.P.P.P.S. Но! Изучая Python - я пришёл к выводу, что у меня допущена архитектурная недоработка. Продиктованная "слепым следованием" парадигме FORTH-машины. Надо помещать в стек и "шитый код" (да и вообще в ЛЮБОЙ контекст вызова) САМО "слово" (объект, в терминах Python), а не результат его выполнения. Тогда не нужно ни ОПЗ, ни "обратное присваивание", ни прочие "трюки".

P.P.P.P.P.S. И ещё я понял - КАК "скрестить ежа ("мой Forth") с ужом (Python)" и задействовать "батарейки в комплекте" от Python'а. В итоге получим ВНУТРИ "стандартность, гибкость и насыщенность" Python и СНАРУЖИ "понятность и гибкость DSL".

19 комментариев:

  1. NameRec:

    «Всё там же "стековая машина" со "словарями".»
    -- Разве это имеет значение?

    «А "синтаксис" без ОПЗ.»
    -- Это я бы считал достоинством :-)

    «Использовать как DSL - не то чтобы прям уж ИДЕАЛЬНОЕ решение.»
    -- Я говорил об использовании Python *вместо* DSL :-)

    «На мой вкус - тоже вполне себе "криптован".»
    -- Что же Вы нашли там "криптованого"?

    «Что касается "словарей" и построения на их основе "классов" - ну "мой FORTH" ровно так и устроен.»
    -- Вы Python с чем-то путаете. В Python имеется полноценная (я не моделированная каки-ми бы то ни было средствами) поддержка классов и всех парадигм ООП.

    «Ну и на закуску:
    def __init__(self):...»
    -- Про "закуску" не понял.
    Ну, разве что, обращу внимание, что Вы привели пример конструкций, которые используются для разработки достаточно низкоуровневых решений средствами Python.

    «--  подобное не кажется мне прям ИДЕАЛЬНЫМ для DSL»
    -- Как выглядит решение Python в стиле ООП я обозначил в своём комментарии здесь: http://roman.yankovsky.me/?p=796
    Никаких переопределений стандартных методов и "шаманств" с пространством имён объектов :-)
    Кстати... :-)
    Ну да ладно...

    «P.S. Хотя про интеграцию Python и Delphi - был бы рад, что-нибудь стоящее почитать.»
    -- Скорее уж, лучше посмотреть: :-)
    1. http://dondublon.livejournal.com/68416.html
    Не обращайте внимания на тезис "про прекращение разработки" - адаптация к новым версиям Delphi и Python продолжается.
    Правда, не всегда теми темпами, что хотелось бы.
    Но что поделаешь - Open Source... :-)

    2. svn checkout http://python4delphi.googlecode.com/svn/trunk/ python4delphi-read-only
    Репозиторий с примерами и документацией.

    ОтветитьУдалить
    Ответы
    1. >Но что поделаешь - Open Source... :-)
      Если бы Open Source сообщество дельлфи было посильнее - то были бы уже приличные биндинги и не одни. Но оно у дельфи слабенькое, к сожалению. =(

      Удалить
    2. "Son of a gun" - вам первое и последнее предупреждение...

      Удалить
    3. Предупреждение о чём? o_O

      Удалить
  2. Вообще же, развивая эту тему, думаю, что могу поделиться личным опытом, когда "собственный DSL" завёл сильно "не туда"...
    Тем более, что уже пообещал Роману.
    Места займёт относительно немного, просто я был личным свидетелем истории разработки собственного DSL для упрощённой генерации отчётов. Мне довелось быть не только пользователем, но и автором, вероятно самой большой программы на этом языке...

    PS: Прошу извинить за обилие смайликов в предыдущем посте. Ничего такого ввиду не имел, просто пока писал, возникла *куча* воспоминаний и ассоциаций...

    ОтветитьУдалить
  3. Мне кажется, что "впечатлить" в этом мире Вас уже ничего не сможет :)

    ОтветитьУдалить
    Ответы
    1. Ну вас я тоже положим пока ничем не удивил :-)

      А в общем - вы конечно же ошибаетесь. Я вполне себе впечатляюсь.

      Вот Джоэл - впечатлил когда-то, да и Мак-Коннел.

      Ну и ещё ряд авторов.

      Удалить
  4. NameRec:

    «" После работы скрипта все объекты типа TPyObject уничтожаюся сами. Если объект представлял собой обертку для вашего рабочего объекта и держал на него ссылку, уничтожение ссылки коректно не делается и вы получите утечки памяти. Я достаточно долго ломал голову, как разрулить этот вопрос, в итоге получил рецепт: сделать у каждого такого TPyObject метод очистки ссылок, вызвать его вручную после работы скрипта, причем - это важно - этот метод должен быть не в деструкторе! Может, есть способ элегантнее, но я его не знаю."

    Дьявол то - он как обычно - в деталях :-)»
    -- Либо я неправильно понял автора процитированного Вами текста, либо автор делает что-то странное.
    Прошу обратить внимание, что Вы читали "вводную статью", в которой человек делится своими (положительными, впрочем) впечатлениями.
    При работе с экземплярами TPyObject достаточно просто аккуратно работать с Py_XIncRef/Py_XDecRef и утечек памяти быть не должно.
    По крайней мере мне, какие-либо архитектурные проблемы с применением Python4Delphi не известны.

    «Может быть ждал "откровения", а оно - не случилось.»
    -- Мне неизвестно, что есть "откровение" в Вашем понимании.
    IMHO Python4Delphi - это не откровение, а простой способ использовать замечательный скрипт-язык в своих приложениях для управления своими объектами, реализованными на Delphi.
    Кроме того, там огромная библиотека (и стандартных и сторонних модулей), которая "за просто так" оказывается в распоряжении Delphi-программиста.
    В результате, например, сообщение по Jabber проще отправить из Python, чем искать соответствующие компоненты для Delphi.

    «А что до "синтаксиса" - тут и обсуждать нечего. Синтаксисы - они разные бывают.»
    -- IMHO - тут не только есть, но и много чего обсуждать.
    Один из преподавателей моего ВУЗа (ушедший от нас, к глубокому сожалению) как-то очень хорошо сказал, правда об операционных системах (цитирую по памяти): "Есть хорошие операционные системы - в них много стандартного. Есть плохие операционные системы - в них много оригинального."
    Позже, я сформулировал для себя вывод, который впрочем, никому не навязываю. Или вы делаете революцию в своей области и, вследствие этого, имеете право на оригинальность, или следуйте правилам, которые складывались годы.
    Именно поэтому я консервативно отношусь к синтаксису (синтаксис Python я вначале воспринял негативно, но позже мне очень понравились его совершенно прагматические следствия), обратной польской записи и прочим вещам, препятствующим восприятию.
    Из того, что порог входа в программировании на Forth выше, чем на любом скрипт-языке, мне и представляется он не лучшим для DSL или чего-то подобного.

    PS: Если показалось, что я излишне категоричен - отнюдь. Мне просто утомительно писать IMHO в контексте каждого предложения.
    Надеюсь, очевидно, что я излагаю *свои* суждения, причём стараюсь приводить развёрнутую их мотивацию.

    ОтветитьУдалить
    Ответы
    1. Статья прямо скажем - спорная. А ведь именно вы дали ссылку на неё. Так что слова "вводная" - не считаются.

      Она прямо скажем - для "гиков". Я то - разберусь. А вот "обычные прикладные" программисты - скорее всего - плюнут и не станут разбираться. Ну или "забьют" на утечки памяти. Как автор статьи. Если я правильно всё понял.

      Удалить
    2. NameRec:

      «Статья прямо скажем - спорная. А ведь именно вы дали ссылку на неё. Так что слова "вводная" - не считаются.»
      -- Мнда... Ну, насчёт "спорности" я возражать не стану.
      Когда я имел ввиду "вводность" - я подразумевал, что ко всем статьям в Сети стоит относиться критически, вместе с тем, автор демонстрирует основные приёмы работы с Python4Delphi.
      Ну и... :-) А на что прикажете давать ссылку, если это чуть-ли не единственный русскоязычный материал по этой теме (с учётом малочисленности сообщества Delphi), а англоязычные - не многим лучше или заметно устарели?
      Хотя мне трудно избавиться от ощущения, что я оправдываюсь...
      Если материал Вас заинтересовал, то рекомендую ознакомиться с примерами из репозитория, там же приводится, IMHO информативное, их текстовое описание, которое мне, в своё время, очень помогло.
      Примеры по-моему, очень просты и иллюстративны.

      «Она прямо скажем - для "гиков". Я то - разберусь. А вот "обычные прикладные" программисты - скорее всего - плюнут и не станут разбираться. Ну или "забьют" на утечки памяти. Как автор статьи. Если я правильно всё понял.»
      -- Мне трудно судить...
      FastMM содержит изощрённые средства по отлову утечек памяти — в наших приложениях контроль утечек по выходу из приложения никогда не отличается и мы проводим расследование по каждому случаю утечек.
      В таком случае можно достаточно быстро выловить все «артефакты» при использовании Python4Delphi.
      Что до «обычных прикладных программистов», то IMHO подключение Python4Delphi к ядру системы — не их уровень. IMHO тут требуется исследовательский подход.

      «P.P.P.P.P.S. И ещё я понял - КАК "скрестить ежа ("мой Forth") с ужом (Python)" и задействовать "батарейки в комплекте" от Python'а. В итоге получим ВНУТРИ "стандартность, гибкость и насыщенность" Python и СНАРУЖИ "понятность и гибкость DSL".»
      -- Ну да... На Python реализацию исполняющей системы DSL обеспечить всяко проще, чем на Delphi... Хотя... ;-)

      Удалить
    3. "На Python реализацию исполняющей системы DSL обеспечить всяко проще, чем на Delphi... "

      Спорно.. Если не говорить о "батарейках"...

      Удалить
    4. "FastMM содержит изощрённые средства по отлову утечек памяти — в наших приложениях контроль утечек по выходу из приложения никогда не отличается и мы проводим расследование по каждому случаю утечек."

      Ну тут про FastMM - тоже... Не для "прикладных программистов"....

      Удалить
  5. NameRec:

    «"На Python реализацию исполняющей системы DSL обеспечить всяко проще, чем на Delphi... "

    Спорно.. Если не говорить о "батарейках"...»
    -- Да нет, совершенно нет... Поверьте, я знаю о чём говорю.
    Ну и "батарейки" - тоже конечно. Там многое проделано.
    Вот http://habrahabr.ru/post/115206/ например, кстати...
    Обратите внимание на объём кода интерпретатора упрощённого Lisp.

    «Ну тут про FastMM - тоже... Не для "прикладных программистов"....»
    -- А его (FastMM) часто можно использовать в режиме чёрного ящика. Там для неосвобождённого блока в режиме FullDebugMode указывается адрес в коде, где он был распределён.
    Да и дамп этого участка есть - это часто очень упрощает поиск причин утечек.
    В любом случае, научить этому не сложно. Не нужно быть "семи пядей", как говорится...

    ОтветитьУдалить
    Ответы
    1. NameRec:

      Поправка:
      «Обратите внимание на объём кода интерпретатора упрощённого Lisp.»
      -- Следует читать: «Обратите внимание на объём кода *реализации* интерпретатора упрощённого Lisp.»

      Удалить
    2. "Обратите внимание на объём кода интерпретатора упрощённого Lisp."
      -- я писал FORTH на БК-0010.01. Там объём кода был <= 4Кб вместе со словарём.

      "-- А его (FastMM) часто можно использовать в режиме чёрного ящика. Там для неосвобождённого блока в режиме FullDebugMode указывается адрес в коде, где он был распределён.
      Да и дамп этого участка есть - это часто очень упрощает поиск причин утечек.
      В любом случае, научить этому не сложно. Не нужно быть "семи пядей", как говорится..."
      -- проблема не в "чёрном ящике" :-) и не в "семи пядях".. :-) проблема - ЗАХОТЕТЬ это сделать :-) только и всего... потому про "прикладных программистов" и говорю... "не хотят".. обычно.. в этом проблема... "не видят НАДОБНОСТИ"...

      Удалить
    3. " http://habrahabr.ru/post/115206/"
      -- я НЕ БУДУ так делать... УЖЕ - "не надо".. но всё равно - СПАСИБО!

      Удалить
    4. Это кстати ОЧЕРЕДНОЙ раз доказывает, что FORT, LISP и Python - "близнецы-братья". Вопрос ТОЛЬКО в "синтаксисе" :-)

      Ну я вас в общем - понял :-)

      Удалить
  6. NameRec:

    «"Обратите внимание на объём кода интерпретатора упрощённого Lisp."
    -- я писал FORTH на БК-0010.01. Там объём кода был = 4Кб вместе со словарём.»
    -- Александр, я Вас умоляю... :-)
    В мои планы совершенно не входило впечатлять Вас килобайтами... :-)

    «-- проблема не в "чёрном ящике" :-) и не в "семи пядях".. :-) проблема - ЗАХОТЕТЬ это сделать :-) только и всего... потому про "прикладных программистов" и говорю... "не хотят".. обычно.. в этом проблема... "не видят НАДОБНОСТИ"...»
    -- А вот здесь - стоп...
    При чём здесь "прикладные программисты" и что значит "не захотят"...
    Если при тестировании аналитик после выхода из программы получает сообщение об утечках памяти, продублированное в log-файла с дампом этих утечек, он совершенно формально ставит задачу на устранение этого *дефекта*.
    Такое "прикладной программист" *технологически* проигнорировать не сможет.
    Что же до обязательного включения протоколирования утечек - это тоже "не ума прикладного программиста" дело - за это архитектор отвечает.
    Впрочем, если соответствующий код по каким-то причинам отключён (что не просто сделать) - ищем виноватого прикладного программиста... :-)

    ОтветитьУдалить
    Ответы
    1. "-- Александр, я Вас умоляю... :-)
      В мои планы совершенно не входило впечатлять Вас килобайтами.."

      Да я понял уже :-) Хотя.. Мои 4 Кб примерно равны 90 строкам на Python.. поверьте..

      "При чём здесь "прикладные программисты" и что значит "не захотят"...
      Если при тестировании аналитик после выхода из программы получает сообщение об утечках памяти, продублированное в log-файла с дампом этих утечек, он совершенно формально ставит задачу на устранение этого *дефекта*."

      Да я ПОНИМАЮ, о чём вы говорите. БОЛЕЕ ТОГО у меня есть СВОИ подобные механизмы. Но я о другом. Если я правильно понимаю. Просто у МЕНЯ - нет таких "административных рычагов", как у Вас :-) Что пожалуй - далее - не стоит обсуждать... Не МОЕГО ума дело...

      Удалить