Выделил свой python wrapper в отдельный проект PyMongoBongo :) github.com []
Придумал, как написать, чтобы было удобно, красиво, и сравнительно быстро!
Я сейчас пишу обертку над более низкоуровневым API python драйвера для MongoDB. Так сказать, чтобы иметь более человеческий интерфейс для доступа к объектам. И вот сейчас у меня небольшая проблемка. Чем поступиться, производительностью или удобством? Если класс документа будет принимать в конструкторе dict, то это будет быстрее, а если **kwargs, то более красиво. Что для тебя важнее?
Только что упала с kernel panic виртуальная машина на которой я работал с MongoDB. После перезагрузки тесты Python драйвера начали выдавать кучу ошибок, но на третьем запуске все тало нормально. Невольно задумаешься о том, стоит ли использовать такую базы в продакшене.
Ура, мое патчи в транке github.com []
Апнул питоновский драйвер для MongoDB и его родные тесты сломались, выдав море ошибок. Полчаса выяснял в чем дело, потом снова запустил тесты и все ОК. Как такое может быть?
Мистическим образом у меня сломалась локальная Django инсталляция — runserver больше не запускается, требует установить переменную окружения DJANGO_SETTINGS_MODULE. Бля, ненавижу подобный подземный стук.
Написал для курсора из MongoDB python клиента поддержку слайсов, и жизнь стала краше! :)
Стоило мне только сегодня зааплодить свою версию django-tagging-ng (0.3.1) на pypi, как Brian Rosner объявляет у себя в твиттере, что только только зарелизил оригинальную django-tagging :))))
Пропихнул маленький, но очень полезный патчик в mock.py by Michael Foord.
Наконец решил синхронизировать свою версию django-tagging-ng с транком django-tagging.
Интересно, что sum на список из timedelta не работает, а вот reduce(operator.add, deltas) выполняется замечательно!
*links читаю про heapq (http://docs.python.org/library/heapq.html)