Уведомления

Группа в Telegram: @pythonsu

#1 Июнь 13, 2008 23:51:30

bialix
От:
Зарегистрирован: 2006-07-13
Сообщения: 774
Репутация: +  1  -
Профиль   Отправить e-mail  

Сканер уязвимостей веб-приложений. Несколько вопросов по архитектуре.

Андрей Светлов
То, что вставили в базаре - съедобно. Но, ИМХО, можно и чуть элегантней. Врочем, это не тот вопрос, по которому нужно всерьез спорить. Так - тоже неплохо.
Снова начинается: съедобно/не съедобно, плохо/не плохо. Из твоей реакции следует, что ты знаешь как сделать лучше. Тогда покажи как сделать элегантней. И в чем будет принципиальная разница.



Отредактировано (Июнь 13, 2008 23:52:25)

Офлайн

#2 Июнь 14, 2008 01:02:03

Андрей Светлов
От:
Зарегистрирован: 2007-05-15
Сообщения: 3137
Репутация: +  14  -
Профиль   Адрес электронной почты  

Сканер уязвимостей веб-приложений. Несколько вопросов по архитектуре.

Да не хочу я делать очень громкие заявления. Извини, что, похоже, получилось именно так.
Для меня “съедобно” = работает, и работает хорошо. Задачу решает.
Чтобы заявлять, что система плагинов в базаре - отстой (никогда не позволю себе такого высказывания просто потому, что она работает и решает свою задачу), а, как ты говорил: “способ импорта - дело филигранной техники, мало кому интересное” - нужно предложить работающий патч к базару, ничего не ломающий и делающий свое дело.
У меня патча нет. И знаком с базаром только как пользователь.
Всего лишь высказываю удивление - но не знаю всех деталей такой сложной системы как базар. Оставляю себе возможность предположить, что разработчики могли в чем-то слегка ошиблись и можно сделать чуть лучше.

Другой вопрос - я решал те же проблемы немного другим путем. Мне он кажется чуть более правильным - возможно, только мне.
И тоже работал - на моих предыдущих проектах.

Принципиальной разницы нет. eval('import …') очень похож на __import__(…)

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

Все выглядит просто и решаемо, но пока только “на словах”. Когда сделаю - возможно, изменю оценку.



Офлайн

#3 Июнь 14, 2008 12:13:04

bialix
От:
Зарегистрирован: 2006-07-13
Сообщения: 774
Репутация: +  1  -
Профиль   Отправить e-mail  

Сканер уязвимостей веб-приложений. Несколько вопросов по архитектуре.

Андрей, я понимаю твою позицию. Просто я знаю как долго писался и переписывался и улучшался тот код, потому что это все происходило практически у меня на глазах. Поэтому многие решения кажутся страными. но они появились не вдруг, а в результате многолетнего использования на разных платформах: Linux, Windows, MacOSX. Какие-то куски кода могут казаться спорными, но за ними история проекта.

Я помню, что давно уже обсуждался вопрос о том, почему бы не использовать __import__ и в результате обсуждения пришли к выводу что его лучше не использовать. Почему – я уже не помню, надо искать в архивах.

Ситуация мне до смешного напоминает критику фреймворков: когда говорят что там много лишнего и надо писать не так.

И кстати использование imp или zipimport дает более богатые возможности: так например можно импортировать модуль с неправильным именем, типа bzrtools-1.2.3. Надо ли это – вопрос отдельный.

P.S. только не eval a exec.



Отредактировано (Июнь 14, 2008 12:14:35)

Офлайн

#4 Июнь 17, 2008 10:51:08

bialix
От:
Зарегистрирован: 2006-07-13
Сообщения: 774
Репутация: +  1  -
Профиль   Отправить e-mail  

Сканер уязвимостей веб-приложений. Несколько вопросов по архитектуре.

Я хотел бы продолжить нашу дискуссию. Вы ж не думали, что я так просто сдамся?
Я могу объяснить разницу между использованием __import__ и exec “import …”

Даже будет проще показать.
Пусть у нас есть файл с именем foo-bar.py

C:\Temp\4>dir

17.06.2008 10:44 0 foo-bar.py
Делаем импорт:

C:\Temp\4>python -c "print __import__('foo-bar')"
< module 'foo-bar' from 'foo-bar.pyc' >
а вот так:

C:\Temp\4>python -c "import foo-bar"
File "<string>", line 1
import foo-bar
^
SyntaxError: invalid syntax
Итого exec нужен для того, чтобы задействовать готовую питоновскую логику по парсингу и проверке имени импортируемого модуля, а также чтобы не писать все те вспомогательные функции, которые показывал Андрей для корректного доступа к модулю в случае __import__('foo.bar.baz').

Так что если вам надо иметь возможность загружать плагин с любым самым фантастическим именем, то __import__ или imp.load_module – ваш выбор.

В Базаре установлена политика, что все имена плагинов должны быть валидными питон-именами для импорта, чтобы плагины могли импортировать друг друга.

Хотелось бы услышать дополнительные вопросы/критику по подходу Базара. Не для того, чтобы доказывать кому-то что подход Базара – рулез. А для того, чтобы вместе разобраться какую проблему решает тот или иной код, который вам кажется странным или неправильным.
Андрей, мне всегда интересно услышать о твоей точке зрения на эту проблему, просто чтобы лучше понять ее, рассмотрев с разных сторон.

PS: вывод из консоли нормально не вставляется при использовании тега code. Это у меня руки или ограничения движка форума?



Отредактировано (Июнь 17, 2008 10:53:43)

Офлайн

#5 Июнь 18, 2008 18:52:13

Андрей Светлов
От:
Зарегистрирован: 2007-05-15
Сообщения: 3137
Репутация: +  14  -
Профиль   Адрес электронной почты  

Сканер уязвимостей веб-приложений. Несколько вопросов по архитектуре.

bialix
Итого exec нужен для того, чтобы задействовать готовую питоновскую логику по парсингу и проверке имени импортируемого модуля, а также чтобы не писать все те вспомогательные функции, которые показывал Андрей для корректного доступа к модулю в случае __import__('foo.bar.baz').
Никаких возражений. Я как-то не задумывался о необходимости проверки имени - все и так работало.
imp.load_module - не надо. Предназначен только для использования в import hook, и снаружи лучше не вызывать. Хотя бы потому, что, если не ошибаюсь, в sys.modules он себя не ложит. И перед загрузкой не проверяет.
__import__ это делает. По сути import - очень тонкая обертка вокруг __import__
Кому как нравиться. Спорить, кажется, не о чем. Откровенно говоря, в свое время я как-то о exec “import blah.blah.blah” in kw не подумал.



Офлайн

#6 Июнь 19, 2008 03:09:28

bialix
От:
Зарегистрирован: 2006-07-13
Сообщения: 774
Репутация: +  1  -
Профиль   Отправить e-mail  

Сканер уязвимостей веб-приложений. Несколько вопросов по архитектуре.

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

Если есть два файла foo.py и foo.pyd (foo.so) – чистый питоновский модуль и сишное расширение, то обычный import загрузит сишное расширение. При помощи imp.load_module можно загрузить любой конкретный файл. Это можно использовать при тестировании обеих реализаций. Питоновская реализация может быть эталоном или макетом алгоритма, который для скорости потом переписывается в виде модуля расширения. Тестировать естественно нужно обе реализации. Но в продакшене для скорости имеет смысл использовать только сишное расширение.



Офлайн

Board footer

Модераторировать

Powered by DjangoBB

Lo-Fi Version