Как поменять местами ключи и значения в дикте?
-
d = {1:2,3:4,5:6}
-
dict(zip(d.values(),d.keys()))
Programming by Python, JavaScript, ActionScript, PostgreSQL, MySQL for Game Creation and Web Develop. Also about Open Source, Debian and Project Management.
Всем привет. Да, знаю, я давно не писал. Ну простите, и как это не банально, был занят. А заставила меня написать одна мысля. И пожалуйста, дочитайте это до конца, потому что или это очень круто или я опять что то не понимаю, и с температурой 38 мне лучше за клаву не садиться.
Кеш. Я им пользуюсь для того, чтобы данные, которые я долго вычисляю — положить в память куда нить, чтоб если они понадобились — быстро их оттуда взять. Ну а если их там нет, то просто пересчитать и положить. Если вы им пользуетесь также, то читайте дальше иначе напишите комментарий, который начнется со слов: «Тю, блин, а я его совершенно по другому юзаю, глянь…»
Т.е. на сетах и гетах все сводится к примерно следующему алгоритму.
где l_value — это ссылка на функцию, значение которой будет получено, в случае если его нет в кеше.
Вот этот умопомрачительный алгоритм у меня лежит в основе кеширования.
Хух… если у вас также, то идете дальше. Надеюсь сейчас осталось достаточно народу.
Прогуливаясь легкой и непринужденной походкой по блогосфере рунете я уже в который раз натыкаюсь на довольно странное решение следующей проблемы.
Если есть какие либо данные которые системе нужны часто, но вычисляются долго, то их прямое получение по алгоритму, описанному выше — просто убивает систему. Потому что как только они пропадают из кеша — все, кому нужны эти данные — начинают скопом — все вместе их получать. Например статистика по пользователям у вас вычисляется 5 сек, а выводится на главной странице, с посещаемостью 50 чел в сек, значит одновременно эти данные будут получать 250 процессов – что, может привести к смерти.
Решение рунета — 2 кеша. В один кладем с одним эксперейшеном, в другой с таким же, но чуть больше. Я думаю многие натыкались на такие решения, но вкратце — если заэкспаирилось в первом — берем из второго, но первый, кто узнал, о том, что заэкспаирилось — пересчитывает.
Тут просто тьма тьмущая узких мест
1.Старт у системы должен быть особый. Т.е. в нулевой точке в кеше уже должны быть часто доступные данные.
2.У вас двойные данные в кеше, т.е. две копии, а ведь часто бывает и такое, что трудновычисляемые данные — это и большие данные.
3.И последнее — если процесс, который вычисляет заекспаревшиеся данные — умирает. То умирают все. Явно теряем в отказоустойчивости.
Кратко опишу свой алгоритм решения, и построенный на нем джанговый кешовый бекенд (за базовый взят мемкешовый).
Если в ячейку с ключем класть не данные, а хеш из двух значений — данные, и время, когда их надо обновить. (ТАДАМ избавились от второго пункта)
А что если ты перед началом вычислений будеш класть в другой системый и уникальный ключ в кеше время, когда первый, начавший вычисления – планирует их закончить. А остольные процессы, которые захотят получить данные и не увидят их — смогут орентироваться на системный ключь, чтоб понимать, что данные скоро будут и их необходимо подождать или мы не дождались и попробуем еще раз. (ТАДАМ избавились от первого и третьего)
А теперь скучный код. Чтоб легче было читать — его необходимо скрестить с алгоритмом, который я описывал выше. И если функция гет — вернет None то эти данные сразу начнут вычисляться.
Небольшой рандом необходим, чтоб все процессы сразу не набросились вычислять после первого сдавшегося, а нарастающий таймаут необходим для быстрого избавления от быстрых данные и размеренного ожидания долгих.
И на всякий случай. Если вы все таки считаете это отличной идее. Кладем это в файлик с незамысловатым названием smart_cache.py рядом с settings.py, а в settings.py записываем
Хоть простой и нативный pdb и так нам давал все что надо, все же приятно понимать, что есть еще чтото, что может сделать наш девелов приятней. WinPDB – одна из этих приятностей (наткнулся на нее вДжанговкой Вики) . Если коротко – это дебагер с приятным пользовательским интерфейсом, которой кросc-платформенный к слову говоря.
Пользовать легко.
Раньше вы коде оставляли:
А теперь получается чуть длиннее:
На сколько я понял, этот пароль нужен для авторизации дебагера в эту точку прерывания. Т.е. как и pdb, rpdb2 отсанавливает выполение в этой строке.
Запускаем winpdb. File => Attach. В появившемся окне вводим наш пароль mysuperpassword. В полученном списке выбираем наш.
Но самое клевое, что теперь мы можем дебагером зацепиться там, где раньше не умели, например wsgi скрипт висит в апаче. Мы можем по средствам этого механизма присосаться и к нему.

И Django Cheet Sheet, кто еще не знает…
И надо будет испытать django-tinymce
Я уже посягал на суверинитет джанги. Но это было давно и не правда. Более того, меня тогда убедили, что делаю я глупости, и я даже убедился сам, в последствии, что на самом деле делаю глупости. Но мысть о том, что urls.py не нужен – не перестает меня беспакоить. Поэтому очередно фин, аморальный бред – называйте как хотите, но мне безумно нравится.
Идея проста. Вьюха и урла всегда вместе – а значит одно должно быть декоратаром для другого.
Итак главный urls.py имеет обычный вид
/someapp/url_view.py – тут у нас сбстно и хранятся вьюхи с урлами. Как видите, декоратор tourl нам земенил запись в urls.py
/someapp/tourl.py – ну и код самого декоратора
Помоему и симпотично и по производительности не бьет. Вобщем конфетка! Что скажите?
PS: Добавил снипет.
PSS: В снипетсах посоветовали добавить functools.wraps
PSS: А еще можно использовать и так
как делать group by в моделях. В доках вещь не очевидная. Работает только с транком.
Если вы хотите пользоваться всеми переменными окружения Django, но при это “находится” не врутри какой либо вьюхи, т.е. код запускается не через Http запрос, а к примеру – через крон, то начинаться этот скрипт у вас должен такими словами, и лежать он должен в коре вашего проекта:
Успехов…
Tags: django, examples, Python, stand alone, tips
Сегодня попробовал, пришел в легкий экстаз….
В какойнить вьюхе, данные которой вам интересны напишите просто
импорт, ясен, можно вынести за вьюху. Это питоновский дебагер. Теперь, когда вы откравить зепрос к этой вьюхе, и он дойдет до указаного места – выполнение остонавливается и в консоле, в которой у вас запущена джанга вы переходите в дебаг.
и в консоле поддерживаются следующие основные комманды:
n – следующая сомманда
s – зайти в рутину
r – выйти из рутины
l [first,[last]] – вывести код, и место, где ты сейчас находишся. Если не указан first и last то выводится текущая позиция. first и last определяет с какой по какую строчки необходимо вывести.
p – вывести результат операции
c – продолжать выполнения программы до следующего брейкпоинта
w – показать текущий стек вызова
q – выйти.
Этого мне пока в полне достаточно. Натолкнулся тут. А еще можно почитать на python.org.
Если чесно, узнай я про енту фикчу прикольную раньше – и спал бы по дольше, и выглядел бы лучше.
Буквально пару строк кода добавили массу дополнительных возможностей.
теперь если функция cp_before возвратит значение – это значит это и будет результатом всего запроса. Появилась функция cp_after которая вызывается в конце всей обработки
результат работы функций cp__* может быть не обязательно наследник HttpResponse, но и любая другая структура языка, которая уже будет преобразована к оному с помощью функции cp_prepare
Вот собственно необходимые доработки в классе AddNewUrl :
теперь, к примеру задача вывода JSON структуры сводится к
Сегодня из интереса написал небольшой модуль сериализации в ХМЛ. На скорую руку. Как по мне – довольно элегантное решение. Как думаете?
Вот, как его мона юзать:
Recent Comments