[noob] python
map+eval.
Судя по второй функции в примере надо еще парсить второй параметр.
asd =[('funct1', 'city=Moscow''funct2', 'n=55&m=1.5''funct7', '')]
map(lambda t: eval("%s(%s)"%(t[0], t[1].replace('&',"',").replace('=',"='") + ("'" if '=' in t[1] else '') asd)
тест
In [51]: map(lambda t: sys.stdout.write("%s(%s)\n"%(t[0], t[1].replace('&',"',").replace('=',"='") + ("'" if '=' in t[1] else '') asd)
funct1(city='Moscow')
funct2(n='55',m='1.5')
funct7
Out[51]: [None, None, None]
import urlparse
asd =[
('funct1', 'city=Moscow'
('funct2', 'n=55&m=1.5'
('funct7', ''
]
for fname, args in asd:
globals[fname](**dict(urlparse.parse_qsl(args
я слишком нуб и не понял пример, но спасибо тебе автор
> globals[fname](**dict(urlparse.parse_qsl(args
вот так более менее понял
вот так более менее понял
я слишком нуб и не понял пример, но спасибо тебе авторЛадно гнать, даже я его понял.
это была реализация предложения ... чисто в качестве упражнения )
но для сурового web-а это конечно не годится из-за возможности инъекции кода через запрос
вообще то что ты хочешь реализовано в mod_python.publisher (модуль питона для апача)
но для сурового web-а это конечно не годится из-за возможности инъекции кода через запрос
вообще то что ты хочешь реализовано в mod_python.publisher (модуль питона для апача)
1) Не используй строковые константы для имён функций, храни сами функции там.
2) иначе используй func_map = {'func1': func1, 'func2': func2, ...} и дальше
Эвал придуман дьяволом чтобы соблазнять скудоумных.
2) иначе используй func_map = {'func1': func1, 'func2': func2, ...} и дальше
for func_name, arg in asd:
func_map[func_name](arg)
Эвал придуман дьяволом чтобы соблазнять скудоумных.
можно я задачу немного изложу?
есть верховный жрец - он может превратить шило в мыло и наоборот, решает вопросы быстро, но не мгновенно - это ядро
чтобы получить от жреца сервис - надо подать ему запрос должным образом
основной поциент - эльфы среднего уровня и тролли-гастролёры
и эльфы и тролли могут подавать запросы не по форме, но тролли могут это делать в автоматическом режиме джаст фор фан
чтобы жреца поменьше досили - он отгораживается одним уровнем бюрократии, который отсеивает заведомо невыполнимые запросы - это точки доступа
если бюрократ не видит причин завернуть поциента - он кладёт заявление клиента на стол жреца
жрец берёт по n(all_queues_states) заявлений из стопки от одного бюрократа, читает, взмахивает волшебной палочкой, ставит печать и кладёт в стопочку обработано и переходит к следующей стопке - это балансировка нагрузки
это была предыстория.
появляется ситуация, что клиенты хотят разного и у этого разного разные параметры, на ум приходит хранить запросы в следующей структуре: (id, access_point, request_timestamp, requested_method, requested_params, reply_timestamp, reply}
как это обычно делается?
есть верховный жрец - он может превратить шило в мыло и наоборот, решает вопросы быстро, но не мгновенно - это ядро
чтобы получить от жреца сервис - надо подать ему запрос должным образом
основной поциент - эльфы среднего уровня и тролли-гастролёры
и эльфы и тролли могут подавать запросы не по форме, но тролли могут это делать в автоматическом режиме джаст фор фан
чтобы жреца поменьше досили - он отгораживается одним уровнем бюрократии, который отсеивает заведомо невыполнимые запросы - это точки доступа
если бюрократ не видит причин завернуть поциента - он кладёт заявление клиента на стол жреца
жрец берёт по n(all_queues_states) заявлений из стопки от одного бюрократа, читает, взмахивает волшебной палочкой, ставит печать и кладёт в стопочку обработано и переходит к следующей стопке - это балансировка нагрузки
это была предыстория.
появляется ситуация, что клиенты хотят разного и у этого разного разные параметры, на ум приходит хранить запросы в следующей структуре: (id, access_point, request_timestamp, requested_method, requested_params, reply_timestamp, reply}
как это обычно делается?
Так, спокойно. eval придуман для кодогенерации в рантайме. То что кто-то используют его не по назначению, это как бы не проблема eval-а 
как это обычно делается?У питона вроде такая реализация сделана через WSGI (web server gateway interface).
Идет request до определенной глубины, по дороге на каждых вратах бюрократ проверяет на определенные параметры и ставит нужную метку (access_point, request_timestamp, request_cookie). В случае успешного прохода через все врата идет обработка (requested_params) и направляется reply в обратную сторону.
Хотя, конечно, можно и разом всё обработать, но тогда верховный жрец сам же будет выступать в роли бюрократа.
> request_cookie
а это чем-то принципиально отличается от того, что у меня в качестве id?
я на самом деле немного о другом: ядро и аксесспоинты на физически разных машинах и хочется, чтобы аксесспоинты не вызывали непосредственно скрипты на ядре, а ставили запросы клиентов в очередь
на стороне аксесспоинта типа так: получил запрос -> проверил корректность -> передал -> свободен
предполагается очередь реализовать таблицей с той структурой, которую я писал до этого
но так как запросы с сильно разными по структуре и количеству параметрами, то вопрос - какой-то компромис между
а) заводить для каждого типа запроса свою таблицу со столбцами под каждый параметр этого типа запроса (отвергнуто, это сложно поддерживать и сложно честно балансировать)
б) завести в одной таблице только 2 столбца method и params и на стороне ядра ломать голову как это всё парсить и не прошляпить injection (отсюда как раз вопрос первого поста)
в) найти другое решение
а это чем-то принципиально отличается от того, что у меня в качестве id?
я на самом деле немного о другом: ядро и аксесспоинты на физически разных машинах и хочется, чтобы аксесспоинты не вызывали непосредственно скрипты на ядре, а ставили запросы клиентов в очередь
на стороне аксесспоинта типа так: получил запрос -> проверил корректность -> передал -> свободен
предполагается очередь реализовать таблицей с той структурой, которую я писал до этого
но так как запросы с сильно разными по структуре и количеству параметрами, то вопрос - какой-то компромис между
а) заводить для каждого типа запроса свою таблицу со столбцами под каждый параметр этого типа запроса (отвергнуто, это сложно поддерживать и сложно честно балансировать)
б) завести в одной таблице только 2 столбца method и params и на стороне ядра ломать голову как это всё парсить и не прошляпить injection (отсюда как раз вопрос первого поста)
в) найти другое решение
ломать голову как это всё парсить и не прошляпить injection (отсюда как раз вопрос первого поста)например для этого в модуле python для apache есть обработчик запросов mod_python.publisher
на access point в конфиге апача прописывается:
<Directory /path/to/dir>
AddHandler mod_python .py
PythonHandler mod_python.publisher
PythonDebug On
</Directory>
скрипт обработки запросов вида "example.com/process_request.py?fun=fun100500&arg1=1&arg2=wow":
# /path/to/dir/process_request.py
import pickle
def index(req,**ka)
# для приведенной строки запроса ka == {'fun': 'fun100500', 'arg1': '1', 'arg2': 'wow"'}
r = pickle.dumps(ka) # сериализуем полученный словарь с именем функции и аргументами
push_to_DB(r) # кладем запрос в очередь
return "JFGI"
в ядре достаем запрос (словарь) из базы, десериализуем его, вызываем нужную функцию с аргументами
globals[ka.pop('fun')](**ka)Все это приправляется валидацией функций и аргументов по вкусу.
Грязную работу при этом делает publisher
pickle.dumps(ka)Сначала был eval, теперь еще и пикл появился.
http://penturalabs.wordpress.com/2011/03/17/python-cpickle-a...
> Сначала был eval
люблю бездумно написать однострочник за утренним кофе )
не люблю играть в телепатию (потипу Fj сходу предложившего "храни сами функции там").
мой пример работал, а до описания конкретной ситуации помочь ТС было всяко затруднительно
> теперь еще и пикл появился.
Сериализация довольно распространненный прием при параллельной обработке данных. Если конкретный (де)сериализатор дыряв, это не значит что надо отказаться от сериализации. Ты же не выбросил свой компьютер на помойку из-за того, что в нем имеются баги.
люблю бездумно написать однострочник за утренним кофе )
не люблю играть в телепатию (потипу Fj сходу предложившего "храни сами функции там").
мой пример работал, а до описания конкретной ситуации помочь ТС было всяко затруднительно
> теперь еще и пикл появился.
Сериализация довольно распространненный прием при параллельной обработке данных. Если конкретный (де)сериализатор дыряв, это не значит что надо отказаться от сериализации. Ты же не выбросил свой компьютер на помойку из-за того, что в нем имеются баги.
Вряд ли автор топика сможет извлечь что-либо полезное из твоих постов - он вроде как интересуется как принято организовывать очереди/отложенное выполнение задач, а не как отвечать на http-запросы с помощью апача.
Так что хорошо бы, чтобы не извлек ничего вредного вроде eval, pickle или засовывания имени функции внутрь сериализованных данных (что потом делать, если захочется посадить разных "жрецов" выполнять разные функции?).
Так что хорошо бы, чтобы не извлек ничего вредного вроде eval, pickle или засовывания имени функции внутрь сериализованных данных (что потом делать, если захочется посадить разных "жрецов" выполнять разные функции?).
> Вряд ли автор топика сможет извлечь что-либо полезное из твоих постов
Чтобы понять почему не надо совать пальцы в розетку, надо разок сунуть пальцы в розетку
> он вроде как интересуется как принято организовывать очереди/отложенное выполнение задач
он интересуется ЧТО ему совать в очередь. саму очередь он и так уже через базу организовал.
> Так что хорошо бы, чтобы не извлек ничего вредного вроде pickle
Я настаиваю, что сериализация - это хорошо, несмотря на проблемы конкретных реализаций.
> что потом делать, если захочется посадить разных "жрецов" выполнять разные функции?
в чем проблема?
Чтобы понять почему не надо совать пальцы в розетку, надо разок сунуть пальцы в розетку
> он вроде как интересуется как принято организовывать очереди/отложенное выполнение задач
он интересуется ЧТО ему совать в очередь. саму очередь он и так уже через базу организовал.
> Так что хорошо бы, чтобы не извлек ничего вредного вроде pickle
Я настаиваю, что сериализация - это хорошо, несмотря на проблемы конкретных реализаций.
> что потом делать, если захочется посадить разных "жрецов" выполнять разные функции?
в чем проблема?
например для этого в модуле python для apache есть обработчик запросов mod_python.publisherПосмотрел: оказывается модпитон ожил и его даже как-то дописывают.
оказывается модпитон ожилДля меня тоже открытие.
> Так, спокойно. eval придуман для кодогенерации в рантайме. То что кто-то используют его не по назначению, это как бы не проблема eval-а
Я, может, неправильно понимаю, но разве это не конфликтует с
> There should be one-- and preferably only one --obvious way to do it?
Правда, они тут же прикрываются
> Although that way may not be obvious at first unless you're Dutch.
Я, может, неправильно понимаю, но разве это не конфликтует с
> There should be one-- and preferably only one --obvious way to do it?
Правда, они тут же прикрываются
> Although that way may not be obvious at first unless you're Dutch.
Я, может, неправильно понимаю, но разве это не конфликтует сПросто питонисты лицемерные лжецы. Этот принципе не работает и не может работать IRL, как и столь же лицемерный христианский принцип непротивления злу насилием.
> There should be one-- and preferably only one --obvious way to do it?
Если чо, это был не наезд на них, мне нравятся многие пропагандируемые ими принципы. Вопрос в том, насколько они (и язык в тех случаях, в которых должен) им следуют.
Ну они пытаются. А если что-то не выходит, то они изо всех сил делают вид, что этого не существует.
Не очень понимаю, в чём заключается противоречие и откуда вообще взялось про "лицемерных лжецов".
Кажется, вы неправильно переводите слова "should" (!= "is" "preferably" и "obvious".
То есть:
1. это всего лишь декларируемая *цель* дизайна языка.
2. should — это относится к тому что "это" можно сделать.
3. а что только одним способом — так вообще "should preferably" — довольно слабое пожелание.
Кажется, вы неправильно переводите слова "should" (!= "is" "preferably" и "obvious".
То есть:
1. это всего лишь декларируемая *цель* дизайна языка.
2. should — это относится к тому что "это" можно сделать.
3. а что только одним способом — так вообще "should preferably" — довольно слабое пожелание.
Не очень понимаю, в чём заключается противоречие и откуда вообще взялось про "лицемерных лжецов".Они все ситхи, чё.
Оставить комментарий
Lord_Max
помогите разобраться, на дотнете вроде такое просто делать, наверное на питоне ещё прощеесть массив:
asd =
{
('funct1', 'city=Moscow'
('funct2', 'n=55&m=1.5'
('funct7', ''
}
и нужно чтобы некоторый код его обошёл и в итоге чтобы выполнилось:
funct1(city = 'Moscow')
funct2(n = '55', m = '1.5')
funct7
это вроде строк в пять должно получаться