Плагины в кармане или перочинный ножик в программе

[bromzh]

Тестовый пример
Комбо: eval в коде, .rar-архив с исходниками, да ещё и на dimonvideo ...

[HeaTTheatR]

А при чем здесь eval? Почему все так боятся eval, забывая, что любой импрот python-модуля — это тоже выполнение кода, суть которого вы не знаете.

[bromzh]

Лично я помню, что импорт eval'ит файл. Просто нужно использовать соответствующие инструменты, вроде import_module. А в третьем питоне так вообще всё получше стало с динамическим импортом всякого.

У вас даже нет обработки ошибок при открытии файла. И кэш тоже не создастся, а это ускорит последующую загрузку.

Ну и да, почему питон-то второй? Киви и третью версию поддерживает.

[HeaTTheatR]

Священный страх перед eval навеян сомнительными личностями из Интерната, мол, не дай бог в строку, которая будет выполнена в eval передадут какой-то ужасный код, форматирующий систему. Берем любой модуль из проекта, пишем код форматирования системы, кидаем обратно в проект… и при чем здесь eval? Вот этого я не понимаю.

Насчет третьего Python.
Не вижу плюсов перед второй веткой. В упор.

[nikolay_karelin]

asyncio?

Насколько я знаю, для многих разработчиков — это именно та killer-feature чтобы перейти на 3-ю ветку.

[HeaTTheatR]

И только? А сколько причин НЕ переходить на ртерью ветку? В десяткип раз больше!

Как и обсуждения eval в комментариях к этой статье, никто не может назвать хотя бы три адекватных причины, почему я должен переходить на третью ветку Python, кроме тех, что, мол, в Интернете все так делают!

[bromzh]

1) Юникод
2) Type hints
3) Nonlocal, yield from, итераторы в коллекциях по-умолчанию. Много модулей, которые в 2,7 только в виде бэкпортов
Ну и 2-ю ветку всё меньше и меньше развивают. Новые фичи не бэкпортнутся.

Ждём десятки причин не переходить на третью ветку.

[HeaTTheatR]

Например, в Python Package Index с Python 3… Сколько и какие пакеты вы можете поставить? Никто из крупных компаний не использует Python3 и не планирует переход не эту мертвую и убогую ветку. Пара тройка пакетов (даже не написанных, а ИНТЕГРИРОВАННЫХ под Python3) явно не устраивают плачущих горе-программистов, которые перешли не эту ветку. Жалобы "портируйте-портируйте-портируйте… " Этого достаточно или еще десяток превести?!

Никаких координальных прорывов в третьей ветки нет! Интерес к ней у разработчиков — постольку-поскольку имидж в сети...

[Pr0Ger]

Жду остальные 10 причин, потому что все пакеты которые хотя бы более-менее популярны уже давно портированы.

А мертвая ветка как раз таки вторая, чей срок поддержки истекает в 2020 году (и изначальный план был полностью закрыть поддержку в 15 году, но Гвидо слишком добрый)

[bromzh]

http://py3readiness.org/
330 из 360 самых популярных пакетов. В реальности, для тройки нет только уж совсем специфичных пакетов, которые и так не особо развиваются. Ещё причины есть?

[HeaTTheatR]

Вы из этих программистов?

[HeaTTheatR]

Если Type hints — причина для вас, чтобы перейти на третью ветку, — то вы, пардон, сумашедший! Лучше бы уже подтвердили мои предположения относительно "потому что в Интернете все так делают!"

[HeaTTheatR]

Насчет ошибок...

Для большей наглядности я убрал из модуля loadplugin.py верефикацию плагинов и различные проверки на отсутствие директории Plugins, файла plugins_list.list и пр.

[kolyaflash]

> В сети можно легко найти достаточно сложные и, порой, запутанные алгоритмы интеграции в ваш программный код подобной системы

Думаю, уж лучше они, чем предложенный.

[HeaTTheatR]

И в чем минус предложенного?

[kolyaflash]

Ну, основной минус в том, что то, что вы сделил — трудно назвать плагинной системой.
Вы сначала переизобрели importlib, завернув это в декоратор (как паттерн), а затем применили… ООП.
В итоге, вместо обещанной плагинной системы имеем обычное приложение с модульную архитектурой и кучей overhead спагетти-кода впридачу.

Ничего личного:
Ваш код ужасен.
Вы, похоже, начинающий Python разработчик. Если это действительно так, то разумнее не публиковать свои <--велосипеды--> перочинные ножики на хабре. Хотя, делать их для себя — действительно хорошая идея.

[HeaTTheatR]

Ага, понял, понял :D

[kolyaflash]

Уточню насчёт ООП. Вы применили ООП как бы принципиально, но не его самого. А ведь именно с помощью классов ваша задача и легко решается. Похоже, именно нелюбовь к (незнанание) ООП и стало проблемой.

[HeaTTheatR]

Видел я, как решаются данные задачи, ага. Возможно я бы и прислушался к вашему комментарию и замечанию насчет «ужасного» кода, но ни разу в глаза ни видя ваш собственный код, оставлю для себя ваши слова пустыми.

[danSamara]

Подобный подход к подгрузке плагинов используют, когда само приложение и плагины разнесены. Например есть основное приложение, а есть доп. функционал, устанавливаемый пользователем. В этом случае оправданы и жёсткое местонахождение плагинов и не очень красивая их загрузка. Я не совсем понял — это ваш случай или нет?
Если же приложение собирает сам автор — можно было реализовать загрузку через сами плагины, типа MyPlugin.register(app). В этом случае получаем больше свободы — нет глобальных объектов, местонахождение непринципиально, структура плагина какая угодно.

[HeaTTheatR]

Да, в статье описан именно тот случай. Плагины создаются и добавляются пользователями. Я отталкивался от простоты конструкции, а не от ее красоты :)

[gigimon]

А как быть с установкой дополнительных плагинов, написаных не вами? Кидать их ручками в вашу папку Plugins, но тогда пропадает возможность использования пакетных менеджеров. Неплохо плагин система сделана в py.test, через встроенные средства setuptools.

[HeaTTheatR]

Ну, я считаю, что файлы, принадлежащие приложению (например, плагины), должны быть в каталоге приложения, а поскольку я люблю организацию, то, да, я считаю, что плагинам место в папке Plugins каталога проекта. Как они туда попадут, по-моему, дело второе.