Таки прочитал топик: «Indeed, you can use Python decorators to implement the Decorator pattern, but that's an extremely limited use of it. Python decorators, I think, are best equated to macros.» Примерно это я и имел в виду, практически дословно получилось :)
Еккель — джавист, его т.н. «книга» Python 3 Patterns является попыткой навязать джавовский классовый подход к питону, а это неправильно. Посмотрим, во что она в итоге выльется, но пока отношение к ней у меня сугубо негативное.
Теперь к теме вопроса. Паттерн Декоратор имеет весьма условное отношение к одноимённой концепции из питона, а именно — питоновский декоратор может использоваться для реализации паттерна, но это очень небольшая часть, для чего он может использоваться. С таким подходом банальную суперпозицию фукций можно тоже объявить реализацией паттерна. Схожесть концепций не более чем схожесть. Наверное, процитированное утверждение может показаться слишком категоричным, я его исправлю.
>— прозрачная работа с транзакциями БД (commit, rollback)
Для этого есть with и контексты, они гораздо лучше справляются с этой работой. Но это уже придирки с моей стороны. Подобных примеров можно найти десятки, они ничуть не лучше уже приведённых. Хотя, конечно, можно привести в качестве иллюстрации. Но повторюсь, они не добавляют бо́льшего понимания, относительно уже приведённых примеров.
Сходство весьма поверхностное. С таким же успехом можно было сравнивать с простой суперпозицией функций во время вызова. Адекватная реализация этого паттерна в питоне смотрится как-то чужеродно, впрочем, как и реализация практически любого объектно-классового паттерна. Но это уже тема отдельной дискуссии и огромного флейма на тему ООП vs. ФП.
«Посчитать время выполнения функции» — это отличный пример, отлично поясняющий суть декораторов. Аналогично с классом Thread. Другие примеры, например, с PyQt и декорированными обработчиками сигналов, используют вещи, далеко не всем знакомые и требующими кучи вводного текста.
Декораторы действительно сильно напоминают AOP, но проблема в том, что связывание декоратора с функцией происходит в момент прохода интерпретатором непосредственно определения функции. Это как минимум одна проблема. Для AOP мне показалось проще использовать тот же aspect.py, чем заморачиваться с декораторами.
Sourceforge, как и другие подобные проекты — это всего лишь хостинг и по нему нельзя в принципе судить о состоянии дел в отрасли. Хотя даже там есть куча проектов, разрабатывающихся коммерческими фирмами (на монстрах типа микрософта и эппла свет клином не сошёлся). В данный момент на том же sourceforge проектом месяца висит www.orangehrm.com/ — опенсорсная разработка коммерческой фирмы. В качестве источника дохода — техподдержка в разной форме. В моей бывшей конторе работает несколько топовых коммитеров в ядро линукса, и активно продвигается большая линукс-подсистема, тоже опенсорсная, но есть и платные расширения.
И ещё раз повторю — на гигантах свет клином не сошёлся. Часто именно из-за своей «гигантскости» они значительно менее гибки в условиях постоянно меняющихся реалий в айтишном секторе. Пока микрософт будет раскачиваться, судорожно согласовывая на сотне уровней какую-либо идею, мелкая фирма выпустит продукт и снимет сливки. Все опенсорсные продукты не делаются одиночками-энтузиастами, таких популярных продуктов очень мало, чаще всего разработчики получают деньги напрямую от результата своих усилий по созданию софта.
Такое комментирование встречается (правда, в форме #if 0) в случае, когда внутри фрагмента уже есть нормальные языковые комментарии и обернуть их стандартно уже нельзя.
Некоторые редакторы, кстати, помечают блок между #if 0 и #endif как комментарий.
Хорошая бизнес-идея. Поскольку я там не участвую, мне все эти нововведения глубоко пофиг. Но судя по возрастающей наглости, идея «монетизации» не приводит к особому оттоку, а наоборот — приносит бабло. Цинично, наверное, звучит, но типа бизнес, никто туда лезть не заставляет.
Да вообще-то практически все (ладно, по крайней мере, очень многие) известные/популярные свободные библиотеки/программы развиваются коммерческими фирмами.
Поскольку используется libreadline, можно пользоваться всеми (практически) его фишками.
Например, поиск в истории по шаблону: нажимаем Ctrl+R и набираем фрагмент строки, которую хотим найти. Alt+Shift+< для перехода к первой записи в истории команд. Alt+Shift+> для перехода к последней.
To associate a label with another control implicitly, the control element must be within the contents of the LABEL element. In this case, the LABEL may only contain one control element. The label itself may be positioned before or after the associated control.
In this example, we implicitly associate two labels with two text input controls:
First Name
Теперь к теме вопроса. Паттерн Декоратор имеет весьма условное отношение к одноимённой концепции из питона, а именно — питоновский декоратор может использоваться для реализации паттерна, но это очень небольшая часть, для чего он может использоваться. С таким подходом банальную суперпозицию фукций можно тоже объявить реализацией паттерна. Схожесть концепций не более чем схожесть. Наверное, процитированное утверждение может показаться слишком категоричным, я его исправлю.
Для этого есть with и контексты, они гораздо лучше справляются с этой работой. Но это уже придирки с моей стороны. Подобных примеров можно найти десятки, они ничуть не лучше уже приведённых. Хотя, конечно, можно привести в качестве иллюстрации. Но повторюсь, они не добавляют бо́льшего понимания, относительно уже приведённых примеров.
«Посчитать время выполнения функции» — это отличный пример, отлично поясняющий суть декораторов. Аналогично с классом Thread. Другие примеры, например, с PyQt и декорированными обработчиками сигналов, используют вещи, далеко не всем знакомые и требующими кучи вводного текста.
Декораторы действительно сильно напоминают AOP, но проблема в том, что связывание декоратора с функцией происходит в момент прохода интерпретатором непосредственно определения функции. Это как минимум одна проблема. Для AOP мне показалось проще использовать тот же aspect.py, чем заморачиваться с декораторами.
И ещё раз повторю — на гигантах свет клином не сошёлся. Часто именно из-за своей «гигантскости» они значительно менее гибки в условиях постоянно меняющихся реалий в айтишном секторе. Пока микрософт будет раскачиваться, судорожно согласовывая на сотне уровней какую-либо идею, мелкая фирма выпустит продукт и снимет сливки. Все опенсорсные продукты не делаются одиночками-энтузиастами, таких популярных продуктов очень мало, чаще всего разработчики получают деньги напрямую от результата своих усилий по созданию софта.
Некоторые редакторы, кстати, помечают блок между #if 0 и #endif как комментарий.
Например, поиск в истории по шаблону: нажимаем Ctrl+R и набираем фрагмент строки, которую хотим найти. Alt+Shift+< для перехода к первой записи в истории команд. Alt+Shift+> для перехода к последней.
Ну, и так далее.
To associate a label with another control implicitly, the control element must be within the contents of the LABEL element. In this case, the LABEL may only contain one control element. The label itself may be positioned before or after the associated control.
In this example, we implicitly associate two labels with two text input controls:
First Name
Last Name