О Python с Игорем Давыденко

Базовая настройка aiohttp.web приложений

2020-01-08T20:22:00.000+02:00

Словил себя на мысли, что несмотря на то, что большинство моих веб-приложений работают на aiohttp.web, их настройка происходит в лучших Django традициях,

Определение настроек в settings.py модуле, как DEBUG = to_bool(os.getenv("DEBUG") or False)
Импорт целого модуля и сохранение его в aiohttp.web приложении, как types.MappingTypeProxy структура
Использование сохраненного маппинга во вью-функциях, как, например, request.config_dict["settings"]["DEBUG"]

И если этот подход работал like a magic 5 лет назад, не говорит о том, что он идеально вписывается в Python в 2020 году. Главные проблемы с тем, как это было сделано ранее, это:

Инстинктивно хочется сделать from app import settings и потом просто settings.DEBUG, вместо того чтоб идти за настройками в request.config_dict
Работать с настройками, которые хранятся как Mapping[str, Any] — это выстрел себе в обе ноги. Никакой mypy не подскажет тебе, есть ли у тебя в настройках ключ VERY_IMPORTANT_KEY и не ошибься ли ты с тем, что считаешь, что PRICE_MULTIPLICATOR это decimal.Decimal, а не float.

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

Нужно хранить настройке в какой-то структуре данных, а что может быть лучше @attr.dataclass для этого?
Нужно упростить получение настроек из окружения для attr.ib (аттрибутов) структуры данных
Ну и куда же без mypy, так что нужно убедиться, что структура данных с настройками будет поддерживать любые типы данных и работать без магических # type: ignore

План рабочий, поэтому на его реализацию много времени не понадобилось. Начал с env_factory:

import os
from typing import Optional, overload, TypeVar

import attr
from rororo.settings import to_bool


T = TypeVar("T")


@overload
def env_factory(name: str) -> Optional[str]:
    ...


@overload
def env_factory(name: str, default: T) -> T:
    ...


def env_factory(name: str, default: T = None) -> Union[Optional[str], T]:
    def getenv() -> Union[Optional[str], T]:
        value = os.getenv(name)
        if default is None:
            return value

        if value is None:
            return default

        expected_type = type(default)
        if isinstance(value, expected_type):
            return value

        try:
            if expected_type is bool:
                return to_bool(value)  # type: ignore
            return expected_type(value)  # type: ignore
        except (TypeError, ValueError):
            raise ValueError(
                f"Unable to convert {name} env var to {expected_type}."
            )

    return attr.Factory(getenv)

Продолжил имплементацией хранения базовых настроек,

import attr

from rororo.settings import setup_locale, setup_logging, setup_timezone


@attr.dataclass(frozen=True, slots=True)
class BaseSettings:
    # Base aiohttp settings
    host: str = env_factory("AIOHTTP_HOST", "localhost")
    port: int = env_factory("AIOHTTP_PORT", 8080)

    # Base application settings
    debug: bool = env_factory("DEBUG", False)
    level: Level = env_factory("LEVEL", "dev")

    # Date & time settings
    time_zone: str = env_factory("TIME_ZONE", "UTC")

    # Locale settings
    first_weekday: int = env_factory("FIRST_WEEKDAY", 0)
    locale: str = env_factory("LOCALE", "en_US.UTF-8")

    # Sentry settings
    sentry_dsn: Optional[str] = env_factory("SENTRY_DSN")
    sentry_release: Optional[str] = env_factory("SENTRY_RELEASE")

    def apply(
        self,
        *,
        loggers: Iterable[str] = None,
        remove_root_handlers: bool = False,
    ) -> None:
        if loggers:
            setup_logging(
                default_logging_dict(*loggers),
                remove_root_handlers=remove_root_handlers,
            )

        setup_locale(self.locale, self.first_weekday)
        setup_timezone(self.time_zone)

И в конце концов осталось только начать использовать это все в create_app фабриках и во вью-функциях.

def create_app(argv: List[str] = None, **options: Any) -> web.Application:
     settings = Settings()
     settings.apply()

     app = web.Application(...)
     app["settings"] = settings

     return app

async def index(request: web.Request) -> web.Response:
     settings: Settings = request.config_dict["settings"]  # For JEDI autocomplete
     if settings.debug:
         print("Hello, world!")
     return web.json_response(True)

В итоге настройки становится проще инициализировать, переопределять, дебажить. А mypy говорит отдельное спасибо и точно оберегает от любых погрешностей, работая с базовым функционалом приложения.

ps. Но в заключение хочется отметить, что жаль, что web.Application не ожидает от пользователя никаких настроек и поэтому каждому разработчику приходится ломать голову в поисках того или иного решения для такой тривиальной задачи.

pss. Если вы заметили, то env_factory содержит два # type: ignore комментария. Хотел бы объяснить зачем они там. Первый на линии с to_bool вызовом из-за того, что mypy не понимает, что T is bool и поэтому выдает ошибку Incompatible return value type. Ну а во втором случае mypy ругается на Too many arguments for "object". Отакої

Сортировка списка с unicode strings

2019-03-10T23:05:00.000+02:00

Думал, что после стольких лет Python уже не удивит меня, однако пословица Век живи, век учись стала для меня как никогда актуальной вчера. Задача была весьма простая: отсортировать список с строками, где строка - это украинское имя, то есть вроде бы все должно быть предельно просто используя Python 3.7.2:

data = ['Андрій', 'Ігор', 'Євген', 'Віталій']
assert sorted(data) == ['Андрій', 'Віталій', 'Євген', 'Ігор']

Но нет, not so fast!

$ python
Python 3.7.2 (default, Jan  4 2019, 12:23:06) 
[Clang 10.0.0 (clang-1000.10.44.4)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> data = ['Андрій', 'Ігор', 'Євген', 'Віталій']
>>> sorted(data)
['Євген', 'Ігор', 'Андрій', 'Віталій']

Интересно. Значит что-то не так с локалью. Нужно установить правильную локаль и попробовать еще раз.

$ python
Python 3.7.2 (default, Jan  4 2019, 12:23:06) 
[Clang 10.0.0 (clang-1000.10.44.4)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import locale
>>> locale.setlocale(locale.LC_ALL, 'uk_UA.UTF-8')
'uk_UA.UTF-8'
>>> locale.setlocale(locale.LC_COLLATE, 'uk_UA.UTF-8')
'uk_UA.UTF-8'
>>> data = ['Андрій', 'Ігор', 'Євген', 'Віталій']
>>> sorted(data)
['Євген', 'Ігор', 'Андрій', 'Віталій']

Хм. Странно. Значит нужно пойти почитать доку locale и найти там функцию, которая будет делать locale compare. Точно же есть такая.

$ python
Python 3.7.2 (default, Jan  4 2019, 12:23:06) 
[Clang 10.0.0 (clang-1000.10.44.4)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import locale
>>> locale.setlocale(locale.LC_ALL, 'uk_UA.UTF-8')
'uk_UA.UTF-8'
>>> locale.setlocale(locale.LC_COLLATE, 'uk_UA.UTF-8')
'uk_UA.UTF-8'
>>> data = ['Андрій', 'Ігор', 'Євген', 'Віталій']
>>> sorted(data, key=locale.strxfrm)
['Ігор', 'Євген', 'Андрій', 'Віталій']
>>> import functools
>>> sorted(data, key=functools.cmp_to_key(locale.strcoll))
['Ігор', 'Євген', 'Андрій', 'Віталій']

Та ладно. Не верю. Все должно работать. Аргх.

После того, как эмоции уляглись, вспоминаю про ICU и думаю, ну ок, точно есть биндинги ICU для Python и там должна быть функция, которую можно будет скормить в key для правильной сортировки значений в списке.

Устанавливаем ICU в систему,

Для macOS:

$ brew install icu4c
$ export PATH="/usr/local/opt/icu4c/bin:$PATH"

Для Ubuntu Linux:
```
# apt install libicu-dev icu-devtools
```

Устанавливаем PyICU,
```
$ poetry add PyICU
```
или по старинке:
```
$ pip install PyICU
```

$ python
Python 3.7.2 (default, Jan  4 2019, 12:23:06) 
[Clang 10.0.0 (clang-1000.10.44.4)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import icu
>>> collator = icu.Collator.createInstance(icu.Locale('uk_UA.UTF-8'))
>>> data = ['Андрій', 'Ігор', 'Євген', 'Віталій']
>>> sorted(data, key=collator.getSortKey)
['Андрій', 'Віталій', 'Євген', 'Ігор']

Фух! Работает! Так что да, чистая правда: век живи, век учись!

ps. В комментариях @xnull поделился еще одним способом сортировки при помощи pyuca библиотеки, которая не требует установки в систему никаких дополнительных зависимостей.

$ poetry add pyuca  # pip install pyuca

$ python
Python 3.7.2 (default, Jan  2 2019, 13:30:18) 
[Clang 10.0.0 (clang-1000.10.44.4)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import pyuca
>>> coll = pyuca.Collator()
>>> data = ['Євген', 'Ігор', 'Андрій', 'Віталій']
>>> sorted(data, key=coll.sort_key)
['Андрій', 'Віталій', 'Євген', 'Ігор']

Настройка Sublime Text 3 для Python разработки

2018-07-16T15:58:00.000+03:00

Выбор редактора (среды для разработки), наверное, главное событие в жизни каждого разработчика. Я тоже поначалу не мог долго определиться какой редактор использовать, но потом, лет 8-9 назад установил Sublime Text и все - вопрос с редактором был закрыт раз и навсегда. Да, за эти года я иногда пробовал научиться работать в vim, но не смог, ну а на новомодные Atom, PyCharm или VS Code я вообще не смотрел. Поэтому я хотел бы рассказать про то, как я использую Sublime Text 3 и почему мне не нужен IDE в 2018 году.

Главная причина, почему мне не нужен IDE - это, конечно, база расширений для Саблайма, которая находится на packagecontrol.io и покрывает любой из языков, на которых я программирую. Так как блог о Python, то я расскажу только о расширениях для Python, но у меня также есть установленные плагины для JavaScript, flow, TypeScript, Elm и Rust.

В Python же все начинается с установки MagicPython от Юрия Селиванова, расширения, которое добавляет поддержку подсветки всех всех новомодных фич Python, и хоть авторы Sublime Text пытаются улучшать поддержку базового Python от релиза к релизу, нам это не нужно после установки и настройки MagicPython.

Дальше. Было бы неплохо иметь автодополнение для Python, да? Поэтому следующим делом, устанавливаем SublimeJEDI от Сережи Русских. Благодаря движку JEDI, который используется в IPython, к примеру, на выходе мы получаем автодополнение нашей мечты. Но для этого в настройках проекта нам нужно сделать две вещи,

Задать путь к python_interpreter, в общем случае это "~/Projects/<project>/.venv/bin/python", чтоб JEDI использовал все зависимости, установленные в проекте
Настроить python_package_paths. Опять же в общем случае это ["~/Projects/<project>"]

Все, теперь мы получили автодополнение к любому import стейтменту и много других фич, опять же благодаря движку JEDI.

Идем дальше. Линтинг. Тут нам нужны SublimeLinter-flake8 и SublimeLinter-contrib-mypy (а куда без type annotations в 2018 то году?). По дефолту, они будут пытаться использовать стандартный Python, установленный в системе, но так как в моем случае набор flake8 плагинов от проекта к проекту отличается, я задаю executable для этих линтеров в файле настройки проекта (<project>.sublime-project) как,

"SublimeLinter.linters.flake8.executable": "~/Projects/<project>/.venv/bin/flake8" для настройки SublimeLinter-flake8
"SublimeLinter.linters.mypy.executable": "~/Projects/<project>/.venv/bin/mypy" для настройки SublimeLinter-contrib-mypy

Отдельно вы возможно захотите настроить сам SublimeLinter, но так или иначе про ошибки линтера мы узнаем куда быстрее и прямо в редакторе.

По большому счету с главными расширениями, которые превращают Sublime Text 3 в удобную среду разработки на Python мы закончили, но мне также хотелось бы упомянуть еще некоторые плагины, которые могут точно пригодиться,

sublack - автоформатирование Python файлов при помощи black. Нужная вещь, когда вы работаете в команде и не хотите на код ревью тратить время о спорах насчет форматирования Python кода.
editorconfig-sublimetext - также в 2018 году не зачем спорить о табах vs пробелах или отступах. Единократно кладем .editorconfig в корень проекта, а дальше Sublime Text 3 автоматически применяет необходимые настройки форматирования для любых файлов.
DocBlockr - упрощает работу с комментариями в коде. Конечно, этот плагин больше применим для JavaScript кода, но и для Python иногда бывает полезен.
GitGutter - просмотр того, как изменился блок кода, прямо в Sublime Text. Очень нужная вещь, для разработчиков, которые не любят бессмысленный закомментированный старый код.
Terminus - и хоть я постоянно держу открытым Terminal.app иногда бывает удобно открыть терминал прямо в соседней вкладке Sublime Text.

Ну и напоследок чуть о внешнем виде. Все это время я использую схему подсветки кода Tomorrow-Night, так что очень был рад, когда настроил Boxy Theme для внешнего вида Sublime Text, используя это же цветовое решение. В итоге, мой Sublime Text выглядит следующим образом,

А вот шаблон настроек, который я использую для своих проектов,

{
    "folders":
    [
        {
            "file_exclude_patterns": [
                ".install*",
                "*.lock",
                "*-lock.json"
            ],
            "folder_exclude_patterns": [
                ".*cache",
                "node_modules"
            ],
            "path": "/Users/playpauseandstop/Projects/<project>"
        }
    ],
    "settings": {
        "python_interpreter": "/Users/playpauseandstop/Projects/<project>/.venv/bin/python",
        "python_package_paths": [
            "/Users/playpauseandstop/Projects/<project>"
        ],
        "SublimeLinter.linters.flake8.executable": "/Users/playpauseandstop/Projects/<project>/.venv/bin/flake8",
        "SublimeLinter.linters.mypy.executable": "/Users/playpauseandstop/Projects/<project>/.venv/bin/mypy"
    }
}

Вот и получается, что Sublime Text 3 с таким набором расширений - это прекрасный редактор для программирования на Python.

Fast Python. В поисках медленного кода при помощи стандартного профайлера

2018-07-01T15:19:00.000+03:00

Думаю все часто сталкивались с ситуацией, когда бизнес приходит и говорит: спасайте, страница Х нашего прекрасного веб-приложения работает медленно. Или, создание репортов стало занимать в два раза больше времени после последнего деплоя. И хорошо, когда ты наверняка знаешь в чем причина и спокойно переходишь к оптимизации медленного кода, но что делать, если ты не уверен, где проблема? Вот про это мы сегодня и поговрим: использование стандартного профайлера для поиска медленного кода.

Сразу оговорюсь, что есть намного более универсальные библиотеки для профайлинга Python приложений, как например, vprof или pyflame, но я хотел бы рассказать именно про cProfile.

Итак, что надо сделать, чтоб отпрофилировать наш код? На самом деле просто запомнить, как запускать профайлер:

$ python -m cProfile -o script.prof script.py

Ну а в Python 3.7 все стало еще приятней, потому что появилась возможность задавать -m для профайлера как:

$ python -m cProfile -o project.prof -m project

После того как скрипт выполнится, мы получим script.prof файл, который теперь можно эксплорить при помощи KCacheGrind. Для этого нужно перевести его в формат, который понимает KCacheGrind, что делает тулза под названием: pyprof2calltree.

$ pyprof2calltree -i script.prof -k

переконвертирует script.prof в дерево вызовов и откроет приятный глазу интерфейс KCacheGrind.

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

В начале project/__main__.py создаю профайлер и запускаю его, если в окружении есть переменная USE_PROFILER
Оборачиваю web.run_app(...) в try/finally и в finally печатаю содержимое профайлера в файл
Потом запускаю приложение как USE_PROFILER=1 python -m project
И наконец делаю нагрузку на необходимый URL при помощи wrk, например как, wrk -t 4 -c 100 -d 30s --latency http://<URL>/api/slow
Все теперь можно выключать приложение и запускать KCacheGrind

Если теперь перевести это все на код, то получится вот такой апдейт для project/__main__.py,

import cProfile
import os

from app import create_app


USE_PROFILER = os.environ.get('USE_PROFILER') == '1'
profiler = cProfiler.Profile()


if __name__ == '__main__':
    if USE_PROFILER:
        profiler.enable()

    try:
        sys.exit(web.run_app(create_app()))
    finally:
        if USE_PROFILER:
            filename = 'project.prof'
            print(f'Dumping profiler to {filename}')
            profiler.dump_stats(filename)
            profiler.disable()

В итоге, в KCacheGrind, находим интересующую вьюху (на моем скриншоте это retrieve_tweets) и ищем почему же она работает медленно.

Таким образом легко понять какие вызовы во вью-функциях работают медленно, какой код вызывается слишком часто и какие части кода можно будет отрефакторить или отоптимизировать. Ну и всегда помните, чем больше нагрузки дали на веб-приложение, чем больше собрали профайлинг данных, тем вы получили более точный отчет, на основе которого можно начинать оптимизацию вашего кода.

Fast Python. Парсинг ISO дат

2017-06-28T17:48:00.001+03:00

Преобразование ISO-даты из строки в объект datetime.datetime (или datetime.date), наверное, одна из самых распространенных и постоянных задач в web-разработке на Python. Количество способов сделать это просто поражает воображение,

In [1]: value = '2017-06-28T16:59:27+0000'

In [2]: import datetime

In [3]: datetime.datetime.strptime(value, '%Y-%m-%dT%H:%M:%S%z')
Out[3]: datetime.datetime(2017, 6, 28, 16, 59, 27, tzinfo=datetime.timezone.utc)

In [4]: from dateutil.parser import parse

In [5]: parse(value)
Out[5]: datetime.datetime(2017, 6, 28, 16, 59, 27, tzinfo=tzutc())

In [6]: import dateparser

In [7]: dateparser.parse(value)
Out[7]: datetime.datetime(2017, 6, 28, 16, 59, 27, tzinfo=)

Использовались функции: datetime.datetime.strptime, dateutil.parser.parse и dateparser.parse.

А ведь еще есть,

In [8]: import arrow

In [9]: arrow.get(value, 'YYYY-MM-DDTHH:mm:ssZZ')
Out[9]: <Arrow [2017-06-28T16:59:27+00:00]>

In [10]: import maya

In [11]: maya.parse(value)
Out[11]: <MayaDT epoch=1498669167.0>

-//-: arrow.get и maya.parse.

И это только вершина айсберга, потому что библиотек для работ с датами в Python не просто много, а очень много (что говорить, если у Django вообще есть своя parse_datetime функция, основанная на регекспе). У той или иной библиотеки работы с датами есть свои плюсы и особенности, но что делать, если нужно быстро конвертировать строки с датами в стандартные объекты datetime.datetime? Как всегда ответ прост: использовать что-то написанное на C с биндингами в Python, в нашем случае - это ciso8601,

In [12]: ciso8601.parse_datetime(value)
Out[12]: datetime.datetime(2017, 6, 28, 16, 59, 27, tzinfo=)

Результаты %timeit - красноречивы,

In [13]: %timeit datetime.datetime.strptime(value, '%Y-%m-%dT%H:%M:%S%z')
17.9 µs ± 516 ns per loop (mean ± std. dev. of 7 runs, 100000 loops each)

In [14]: %timeit parse(value)
99 µs ± 1.1 µs per loop (mean ± std. dev. of 7 runs, 10000 loops each)

In [15]: %timeit dateparser.parse(value)
1.61 ms ± 39.2 µs per loop (mean ± std. dev. of 7 runs, 1000 loops each)

In [16]: %timeit ciso8601.parse_datetime(value)
2.08 µs ± 67.6 ns per loop (mean ± std. dev. of 7 runs, 100000 loops each)

Итого: Если нужно быстро парсить ISO даты: используйте ciso8601.parse_datetime, если нужно быстро парсить не ISO даты: сначала попробуйте стандартный datetime.datetime.strptime, потом dateutil.parser.parse и только в случае особой и острой необходимости dateparser.parse и прочие библиотеки, основанные на нем.

ps. Результаты приведены для Python 3.6.1, на Python 2.7.13 соблюдаются такие же показатели, но в 2.7.13 в стандартном strptime не было возможности разобрать +0000, потому что ValueError: 'z' is a bad directive in format '%Y-%m-%dT%H:%M:%S%z'.

Fast Python. Выпуск 1. Обновление словарей

2015-03-11T09:00:00.000+02:00

Привет! Запускаю раздел Fast Python, в котором буду делиться простыми рецептами про то, как ускорить и оптимизировать выполнение кода на Python.

Первый выпуск будет посвящен обновлению данных в словарях. Словари - одни из найболее часто используемых типов данных в Python. И сколько времени я с ними не работаю, у меня никогда не возникал вопрос как правильней обновить данные в словаре. Я для себя всегда отвечал на него, что правильней обновлять используя метод update, но сегодня с утра наткнулся на твит от Брэда Монтгомери и мой мир изменился.

Оказывается, что более правильным с точки зрения скорости является обновление словаря через поочередное присваивание значений, чем единичный апдейт. Не верите? Результаты замеров весьма красноречивы:

Python 3.4.3

In [2]: timeit("d = {}; d.update({'first': 'first', 'second': ['one', 'two', 'three'], 'third': True})", number=1000000)
Out[2]: 0.9664371280086925

In [3]: timeit("d = {}; d['first'] = 'first'; d['second'] = ['one', 'two', 'three']; d['third'] = True", number=1000000)                                      
Out[3]: 0.4200690069992561

Python 2.7.9

In [2]: timeit("d = {}; d.update({'first': 'first', 'second': ['one', 'two', 'three'], 'third': True})", number=1000000)
Out[2]: 1.0035829544067383

In [3]: timeit("d = {}; d['first'] = 'first'; d['second'] = ['one', 'two', 'three']; d['third'] = True", number=1000000)
Out[3]: 0.5186400413513184

Bonus: PyPy 2.4.0

>>>> timeit("d = {}; d.update({'first': 'first', 'second': ['one', 'two', 'three'], 'third': True})", number=1000000)                                               
0.10811400413513184
>>>> timeit("d = {}; d['first'] = 'first'; d['second'] = ['one', 'two', 'three']; d['third'] = True", number=1000000)                                         
0.005925893783569336

Итого: Если вы где-то в коде увидите обновление одиночного или множественных элементов словаря через .update - смело переписывайте этот фрагмент на использование __setitem__.

Fast Python:

data['key'] = 'value'
data['another-key'] = 'another-value'

Slow Python:

data.update({
    'key': 'value',
    'another-key': 'another-value',
})

UPD: Михаил Кривушин (deepwalker) в комментариях объяснил почему так происходит:

По дороге создается еще один словарь, и потом уже из него копируются элементы
https://gist.github.com/Deepwalker/c52a74c26df0707dd303

UPD2: Если ключи словаря не используют специальных символов и являются валидными Python ключами, то лучше использовать синтаксис .update(key='value'), вместо .update({'key': 'value'}):

Python 3.4.3

In [2]: timeit("d = {}; d.update(first='first', second=['one', 'two', 'three'], third=True)", number=1000000)
Out[2]: 0.88018084000214

Python 2.7.9

In [2]: timeit("d = {}; d.update(first='first', second=['one', 'two', 'three'], third=True)", number=1000000)
Out[2]: 0.7820448875427246

PyPy 2.4.0

>>>> timeit("d = {}; d.update(first='first', second=['one', 'two', 'three'], third=True)", number=1000000)
0.010169029235839844

Upgrade your pip & virtualenv now

2015-02-16T11:37:00.000+02:00

Странно, что несмотря на очень давний выход pip 6.0 и virtualenv 12.0, многие Python разработчики все еще сидят на более ранних версиях этих незаменимых утилит.

Мой вам совет - обновляйте свой pip & virtualenv сейчас же!

Главная причина - это, конечно, встроенный в pip, толковый и включенный по умолчанию менеджер скачанных зависимостей. Да, и раньше можно было пользоваться опцией --download-cache или конфигом:

[install]
download_cache = /path/to/pip-cache

в ~/.pip/pip.conf, но старый менеджер загрузок был скорее дополнительным, чем полностью готовым к использованию механизмом. Более детальный ход разработки менеджера загрузок хорошо продемонстрирован на GitHub.

Из остального в новом pip ведется проверка версий относительно PEP 440, а значит, что, к сожалению, лучше попрощаться с версиями: X.Y-dev, которые хоть и не попадают на PyPI, но очень часто используются в разработке.

Celery воркер зависает на "mingle: searching for neighbors"

2014-08-25T15:12:00.000+03:00

Сегодня ВНЕЗАПНО все Celery воркеры перестали принимать любые задачи, при том что RabbitMQ (используется в качестве брокера) очереди были пустыми, а остальные части системы функционировали нормально. Не помогала ни перезагрузка Celery воркеров, ни перезагрузка RabbitMQ сервера.

После недолгого копания по логам проблема была локализирована, любой Celery воркер как будто зависал на моменте поиска соседей, оставляя в логах что-то такое:

2014-08-25 14:29:12 [INFO:celery.worker.consumer] Connected to amqp://guest:**@127.0.0.1:5672//
2014-08-25 14:29:12 [INFO:celery.worker.consumer] mingle: searching for neighbors

Быстрый гуглинг указал на существующую Celery issue, а уже в ней и нашелся ответ на проблему. Оказывается на корневом разделе подошло к концу место (было доступно порядка 150 Мб) и Celery в связке с RabbitMQ зависала не показывая никаких признаков жизни. Все починилось банальной чисткой корневого раздела, но осадок остался и на себя, что не поставил уведомления о заканчивающемся месте на корневом разделе и на Celery, что она никаким образом не пытается обработать эту ситуацию и проблему приходится вычислять окольными путями.

Range для не целых чисел

2014-05-04T09:58:00.000+03:00

Почему-то никогда не думал, что range (и xrange) понимают только целые числа (в Python 3 ситуация такая же) и функцией нельзя воспользоваться, как например:

range(0., 5., .5)
range(Decimal('0'), Decimal('10'), Decimal('1.5'))

Поэтому пришлось сделать свою замену:

import operator


def arange(start, stop=None, step=None):
    """
    Implement range function not only for integers as Python's builtin
    function, but for Decimals and floats as well.

    Returns generator with arithmetic progession, not list.
    """
    klass = type(start)
    lt_func = operator.lt

    stop = start if stop is None else stop
    start = klass(0) if start == stop else start
    step = klass(1 if step is None else step)

    assert isinstance(stop, klass), (
        'Start and stop limits have different types, {0!r} != {1!r}.'.
        format(type(start).__name__, type(stop).__name__)
    )
    assert step, "Step shouldn't be a zero: {0!r}.".format(step)

    if start < stop and step < 0 or start > stop and step > 0:
        raise StopIteration
    elif start > stop and step < 0:
        lt_func = operator.gt

    while lt_func(start, stop):
        yield start
        start += step

В отличии от range в Python 2 arange отдает генератор, а не список, что вообщем-то удобней и правильней, ну и функция всегда вернет элементы такого же типа, как были переданы в start и stop аргументы, даже если шаг - это целое число или он не указан вовсе.

Как всегда код оформлен как Gist на GitHub'е, там еще доктесты и юниттесты.

Миграция с Posterous на Blogger

2013-04-25T17:18:00.001+03:00

Как вы, наверное, знаете Twitter сначала купил Posterous, а потом его закрыл. И так как на Posterous'е был мой блог, я перенес все посты из него сюда. Сорри, если RSS фид обновился слишком рьяно.

Если у кого есть схожая проблема и он еще не перевез никуда свой Posterous, вот есть маленький скриптик, который делает всю работу.

зы. Так как этот блог стал моим единственным, то я сменил его название на более честное. Впредь тут будут появлятся информация и по Flask'у, и по Django, но в большинстве случаев думаю просто по Python'у.

Запускаем gunicorn из Python'а

2012-12-20T22:49:00.000+02:00

Иногда бывает надо запустить gunicorn внутри Python скрипта, например, в manage.py. Конечно всегда можно воспользоваться subprocess.call:

import subprocess


app = 'package.module:app'
host, port = '0.0.0.0', 8000
subprocess.call('gunicorn -b {}:{:d} -w 4 {}'.format(host, port, app))

Но как-то это не комильфо подумал я и решил найти более труЪ-способ :)

Решение пришло не сразу, но пришло, надо всего лишь переопределить sys.argv и вызвать метод run,

import sys

from gunicorn.app.wsgiapp import run


app = 'package.module:app'
host, port = '0.0.0.0', 8000
sys.argv = [
    sys.argv[0],
    '-b', '{}:{:d}'.format(host, port),
    '-w', '4',
    app
]
run()

Не очень круто вышло, не находите? А все потому что gunicorn еще использует устаревший optparse для парсинга аргументов с коммандной строки, а там задавать список аргументов в parse_args совсем не обязательно, ведь по дефолту берется список sys.argv[1:].

Так что на таком простом примере лично мне ясно видно, насколько optparse устарел и как вашему приложению, которое его еще использует надо сломя голову переезжать на argparse! И это я еще не рассказал вам о бесподобном управлении под-коммандами в argparse :)

Чиним gunicorn'овский Internal Server Error

2012-11-29T13:37:00.000+02:00

Если вдруг, после запуска gunicorn перестал работать и показывает ошибку похожую на:

Internal Server Error

Traceback:

Traceback (most recent call last):
  File "/Users/playpauseandstop/Projects/project/env/lib/python2.7/site-packages/gunicorn/workers/async.py", line 45, in handle
    self.handle_request(req, client, addr)
  File "/Users/playpauseandstop/Projects/project/env/lib/python2.7/site-packages/gunicorn/workers/async.py", line 73, in handle_request
    resp, environ = wsgi.create(req, sock, addr, self.address, self.cfg)
  File "/Users/playpauseandstop/Projects/project/env/lib/python2.7/site-packages/gunicorn/http/wsgi.py", line 161, in create
    path_info = path_info.split(script_name, 1)[1]
IndexError: list index out of range

то это говорит о том, что какая-то сволочьое-то приложение установило переменную окружения SCRIPT_NAME, которую gunicorn не может нормально обработать. Чтобы пофиксить, просто удаляем переменную окружения,

$ unset SCRIPT_NAME

и перегружаем страницу (ну можно еще перегрузить gunicorn для пущей важности). That's all!

Валидация Django моделей, пять советов

2012-11-08T12:22:00.002+02:00

Не думаю, что для кого-то открою Америку, сказав что в Django есть валидация не только для форм, а и для моделей :) Однако судя по моей практике это чуть спорное, но весьма полезное решение не спешат повсеместно использовать и городят свои велосипеды для проверки значений при создании/обновлении моделей. Поэтому хочу поделиться несколькими простыми советами по этой теме.

Во-первых, храните валидаторы отдельно от моделей. Хранение всех валидаторов в models.py неимоверно раздувает и без того не маленький модуль моделей (а иногда это и пакет), хранение же валидаторов в validators.py решает эту проблему и логично выносит все операции по проверке значений/уникальности модели в подходящее для этого место. Ну и сюда же, не пишите сложные проверки в Model.clean, Model.validate_unique методах, просто вызывайте необходимые функции валидации из validators.py, например:

models.py

from django.db import models

from .validators import validate_complex_case, validate_unique


class Card(models.Model):
    ...
    def clean(self):
        validate_complex_case(instance)

    def validate_unique(self, exclude=None):
        validate_unique(self)
        return super(Card, self).validate_unique(exclude)

validators.py

from django.core.exceptions import ValidationError


def validate_complex_case(instance):
    if instance.name == 'XXX' and instance.path != '/path/to/XXX':
        raise ValidationError('Please provide proper path for the card.')


def validate_unique(instance):
    manager = instance._default_manager
    other = manager.filter(name=instance.name)

    if other.count():
        message = 'Card with this Name already exists.'
        raise ValidationError({'__all__': [message]})

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

В-третьих, не забывайте, что валидаторов может быть сколько угодно много. Старайтесь разбивать большие валидаторы на маленькие атомарные функции и выносить их в core.validators или project.validators, чтоб иметь возможность использовать их не только для текущего приложения, а и для любых других приложений в проекте. Аттрибут validators у поля модели принимает список валидаторов, так что Вы вполне можете писать,

from django.core.validators import MaxLengthValidator, MinLengthValidator
from django.db import models

from .validators import validate_markup


class Card(models.Model):
    ...
    comment = models.TextField(validators=[
        MinLengthValidator(10), MaxLengthValidator(1000), validate_markup
    ])

В-четвертых, валидация модели автоматически не вызывается, когда вы хотите сохранить модель не из админ-панели или ModelForm'ы. Т.е., просто добавление валидаторов в поля модели и задание методов clean или validate_unique не гарантирует, что неправильные данные не сохранятся в базе данных после Model.objects.create или instance.save(). Для того, чтобы обезопасить себя и включить валидацию и для моделей, используйте сигналы:

from django.db import models
from django.db.models import signals
from django.dispatch import receiver


class Card(models.Model)
    ...


@receiver(signals.pre_save, sender=Card)
def validate_card(instance):
    instance.full_clean()

Ну и в-пятых,

Не забывайте про стандартные валидаторы Django
Импортируйте исключение ошибки валидации как from django.core.exceptions import ValidationError
Для моделей нельзя писать методы clean_FIELD как для форм
Валидация модели при вызове instance.full_clean() идет в следующей последовательности: валидация полей (instance.clean_fields()), вызов instance.clean(), проверка на уникальность (instance.validate_unique())

зы. Код и принципы данного материала актуальны для Django 1.3 ветки (да я так и не пересел на 1.4 или 1.5 потому что не вижу в этом особого смысла), может в новых версиях что-то поменялось, уточняйте в документации :)

Learn Python

2012-10-30T22:25:00.000+02:00

Идея вести курсы по Python пришла ко мне довольно давно, как никак за 6 лет активной разработки разнообразных веб-сервисов и приложений на Django, а потом и на Flask, появилось много различных правильных решений, техник и советов, которыми хочется поделится с коллегами и начинающими питонистами. И так удачно совпало, что Андрей Светлов со своей стороны заинтересовался моей идеей и также решил помочь мне в ее реализации.

Так что встречайте, курсы по углубленному изучению Python в Киеве. Курсы будут проходить в 2 потока по 12 занятий, один из которых, web, буду вести я, а второй, advanced - Андрей. Каждое занятие будет длиться 2 часа, по часу на теоретический материал и на разбор домашнего задания. Главной целью web потока будет создание рабочего веб-приложения и обучение безболезненой работы в команде, используя фреймворки Django или Flask. В свою очередь в advanced потоке будут убиты два зайца, с одной стороны курсы будут направлены на помощь в переходе с Python 2.x на Python 3.x, а с другой стороны на детальное изучение как работает веб на примере создания собственного простого веб-сервера.

Курсы направлены на программистов уже знакомых с Python'ом, имеющих определенный опыт его применения и которые хотят более детально залезть под "капот" и разобраться как же все устроено. Не говорю, что курсы полностью не подходят для новичков, главное, конечно, стремление, но поверьте, не подготовленным программистам может прийтись очень тяжело. Также еще раз упомяну, что каждую неделю будут задаваться домашние задание, выполнение которых будет необходимым. Так что курсы направлены и на усидчивых программистов тоже :)

Окончательная стоимость курсов определится после набора групп, ориентировочно 150 грн за занятие. Оптимальный размер группы, 10-15 человек, не хочется терять диалог с посетителями курсов с одной стороны, а с другой стороны превращать все в балаган.

Больше информации доступно на сайте, Learn Python.

зы. Также сразу отвечу по поводу удаленных курсов, такая идея есть, но сходу ее реализовывать не охота, так как пилотный выпуск и так будет непредсказуем, а удаленные курсы только усложнят коммуникацию.

Изменяем заголовки по умолчанию в имейлах от Flask-Security

2012-10-27T16:52:00.000+03:00

Flask-Security - незаменимое расширение, если вам надо быстро и безболезнено реализовать поддержку регистрации, логина, восстановления пароля для вашего Flask приложения.

Однако с ним есть маленькая беда. Дело в том, что все заголовки писем, отправляемых при его помощи захардкожены как строки в коде, а для того или иного приложения есть смысл в замене темы сообщения 'Welcome' на 'Подтвердите ваш аккаунт' и тд.

Благо кастомизация отпарвки сообщений таки была предусмотрена автором, только не думаю, что именно это он имел ввиду, когда добавлял для стейта расширения аттрибут _send_mail_task. Так или иначе, если нам нужно взять и поменять какую-то тему сообщения на новую мы можем сделать это так,

appname/app.py

from flask import Flask
from flask.ext.security import Security

from appname.utils import send_mail


app = Flask('appname')
...
security = Security(app, datastore)
app.extensions['security']._send_mail_task = send_mail

appname/utils.py

from flask import current_app
from flask.ext.babel import gettext as _


def send_mail(message):
    if message.subject == 'Welcome':
        message.subject = _('Confirm your account')

    mail = current_app.extensions['mail']
    mail.send(message)

Совсем не красивое, но рабочее решение. Также я разместил новый тикет на трекере проекта, посмотрим, что скажет автор на мою попытку сделать кастомизацию заголовков более натуральным способом, через задание их в настройках приложения аналогично контекстным сообщениям, которые генерируются Flask-Security.

UPD. Не только меня волновала эта проблема и посему благодаря фиксам Anthony Plunkett в версии 1.5.1 заголовки сообщений от Flask-Security можно задавать в настройках проекта как:

SECURITY_EMAIL_SUBJECT_REGISTER = 'Confirm your account'

Все доступные настройки описаны в документации.

Flask-Script или улучшенный manage.py для Flask приложений

2012-09-06T18:10:00.000+03:00

Наверное, ни один из моих Django-проектов не обходился без пары-тройки кастомных команд, благо эта возможность была одним из столбов архитектуры Django-проекта. Да, написание кода для этих кастомных команд иногда заставляло схватываться за голову и вопрошать: "Why so hard?", но сегодня я не про это.

А про расширение Flask-Script, которое добавляет схожий функционал уже в Flask-приложения и проекты. Думаю, про это расширения многие наслышаны, но до недавнего времени использовать его было очень затруднительно из-за того, что автор на какое-то время ушел от дел и форки приложения добавляющие и правящие одну или две неточности появлялись как грибы после дождя. Но, хвала высшим силам, в прошлом месяце Шон Линч решил покончить с беспределом и выпустил версию 0.4.0, которая просто не оставляет нам оправданий на вопрос, почему до сих пор Flask-Script не добавлен в список зависимостей нашего проекта.

Использовать расширение очень просто и понятно, инициализируем инстанс менеджера, добавляем кастомные команды, запускаем менеджер, если был вызван Python-скрипт. Пример использования, app.py:

from flask import Flask
from flask.ext.script import Manager


app = Flask(__name__)
manager = Manager(app)

@manager.command
def hello():
    """
    Hello, world!
    """
    print('Hello, world!')


if __name__ == '__main__':
    manager.run()

(env)$ python app.py
Please provide a command
  hello      Hello, world!
  runserver  Runs the Flask development server i.e. app.run()
  shell      Runs a Python shell inside Flask application context.

И так как в дефолтной поставке сразу доступны две команды, runserver и shell, мы можем запускать девсервер даже не добавляя строчку app.run() в наш app.py, удобно.

Но описанный подход подходит только для демонстрационных или маленьких приложений, в реальной же жизни мы переносим инициализацию и/или запуск менеджера в давно знакомый нам manage.py:

from flask.ext.script import Manager

from app import app


manager = Manager(app)


@manager.command
def hello():
    """
    Hello, world!
    """
    print('Hello, world!')


if __name__ == '__main__':
    manager.run()

Лирическое отступление. Если честно, я еще точно не определился с тем как более православно объявлять инстанс менеджера и где размещать все кастомные команды. Внутри, хочется объявлять менеджер в app.py, а затем все команды описывать в commands.py, но пока весь код для кастомных команд хранится именно в manage.py, а вот инстанс менеджера таки инициализируется в app.py. Однако почему-то не могу я такой подход порекомендовать всем, так что остановлюсь пока на варианте автора расширения.

Для любителей классов предусмотрена возможность наследовать команды от Command базового класса, но мне по душе ближе использовать функции, этого ой как не хватало в стандартной поставке Django.

В остальном у проекта есть отличная документация, так что пользуйтесь, пользуйтесь и еще раз пользуйтесь!

argparse, format и six или мои маленькие радости

2012-07-24T19:00:00.000+03:00

Скажем прямо, optparse был хорошим решением для Python 2.3, когда в нем была только обертка над getopt. Но время шло и народ требовал нового решения, составлял PEP'ы и наконец принимал argparse в состав Python 2.7+. Однако на argparse я пересаживался долго. Вот прошло уже больше года с моего окончательного перехода на 2.7 ветку, а я все пытался парсить опции и аргументы, приходящие в Python-скрипт, при помощи optparse. Последние пару недель меня убедили что очень зря! С argparse я теперь могу разбирать не только опции, но и аргументы. Никакого больше,

parser = OptionParser(...)
...
options, args = parser.parse_args()

только,

parser = ArgumentParser(...)
...
args = parser.parse_args()

только так! В целом преимущества нового подхода над старым расписаны в документации и в паре других статей. Так что не буду повторятся, просто посоветую и вам использовать argparse и забить на optparse as soon as possible.

Примерно похожая на ситуацию с optparse, у меня была ситуация с форматированием строк. Я продолжал грызть кактус использовать синтаксис 'Hello, %s!' % 'world' вместо модного и молодежного 'Hello, {0}!'.format('world'). И опять же пару последних недель расставили все по местам. После окончательного ознакомления со всеми возможностями Format String Syntax, я просто понял, что назад дороги нет! Только format, только так!

И да, ведь встроенная функция format может использоваться не только для форматирования строк, но и для любых других объектов, которые поддерживают метод __format__. Например, сейчас нет необходимости пользоваться strftime для объектов из библиотеки datetime, просто пишем,

format(datetime.date.today(), '%Y-%m-%d')

или даже,

'{:%Y-%m-%d}'.format(datetime.date.today())

и вуаля!

А напоследок скажу, что также в последнее время часто задумываюсь о необходимости изучения Python 3 или хотя бы портирования какого-то своего кода на эту ветку. И как по магии, в своем фиде на GitHub нашел полезную библиотеку six, которая весьма мне пригодится в этом деле. Вот такие вот дела!

Перенаправляем потоки в pbs

2012-07-18T18:03:00.000+03:00

Мне нравится pbs. Эта библиотека с лихвой заменяет мне необходимость программировать всякие мелкие штуки на чистом bash'е. Однако до сегодня я не особо понимал как реализовать перенаправление потоков. И вот я наконец-то понял, о чем с вами и поделюсь :)

Итак, предположим, что нам неодходимо эмулировать следующую конструкцию:

$ git archive HEAD --format=zip --prefix=project/ > ../project.zip

В pbs это будет выглядеть как-то так:

handler = open('../project.zip', 'wb+')
pbs.git('archive', 'HEAD', format='zip', prefix='project', _out=handler)
handler.close()

Также просто будет перенаправить stderr в необходимый нам файл, например:

$ stat does_not_exist.txt 2> error_log

handler = open('error_log', 'wb+')
try:
    pbs.stat('does_not_exist.txt', _err=handler)
except pbs.ErrorReturnCode:
    pass
handler.close()

Вот такие пироги! Пользуйтесь pbs, это по-настоящему удобная и простая библиотека!

Копируем виртуальные окружения с помощью virtualenv-clone

2012-07-13T14:29:00.000+03:00

Думаю, что идея копирования (клонирования) виртуальных окружений далеко не нова, особенно для всяких деплоймент-сервисов, которые предоставляют доступ к базе как какого-то коммита, так и дефолтной стейджинг ветки. Однако до сегодняшнего дня я не особо понимал как ее верно реализовать.

Для начала еще раз поясню саму идею. Есть репозиторий, есть деплоймент сервис, который для каждого коммита может генерировать код/базы данных/бутстрап проекта/что-угодно и выдавать на гора результат в виде готового для доступа URL-адреса. Для вытаскивания кода и расположения его в определенной директории могут использоваться разные подходы, как впрочем и для работы с базой данных. Но бутстрап проекта для уже готовой базы данных хочется сделать просто:

$ virtualenv --distribute --system-site-packages env
$ . env/bin/activate
(env)$ pip install -r requirements.txt
(env)$ deactivate
$ cp project/settings_local.py{.deploy,}

И вроде бы все работает, но чем больше становится зависимостей и чем больше коммитов приходит на деплой тем система начинает работать все медленней и медленней и постоянно задыхается на этапе pip install -r requirements.txt. Не хорошо!

Потом появляется решение: надо просто сделать основное виртуальное окружение, а потом для каждого коммита копировать его и накатывать уже свежие изменения файла зависимостей и вуаля. Но вместе с решением приходит и вопрос, а как-то это реализовать? Чтоб оно работало то?

Первая идея была очень интересной: а что если новое виртуальное окружение создавать в активированом основном виртуальном окружении? YO DAWG, не иначе. В итоге получилось так же если б мы просто создали новое виртуальное окружение, локальные зависимости основного окружения не были доступны в новом окружении.

Второй идеей было использование --relocatable опции для основного окружения. Результат: после копирования окружения и установки зависимостей, зависимости обновлялись и в основном окружении, а это нам совсем не нужно.

Третьей идеей было таки спросить у гугла "python virtualenv copy" на что гугл выдал мне ссылку на virtualenvwrapper, откуда я путем быстрого рисёрча исходников попал на virtualenv-clone и радостно захлопал в ладоши - то, что нужно!

Так что задача полноценного копирования виртуальных окружений решается просто:

$ sudo pip install virtualenv-clone
$ virtualenv-clone env_base env_new

зы. Еще одним решением для ускорения установки зависимостей была, есть и остается опция --download-cache для pip'а. Но хотелось именно решить вопрос с копированием виртуальных окружений.

зыы. Если кого интересует, весь процесс поиска решения доступен в гисте на гитхабе. Конечно, комментарии и возражения как всегда приветствуются!

Наконец-то, django-discover-runner от Янниса Лейдла

2012-05-21T07:15:00.000+03:00

Эта была долгая история полная костылей, но кажется лед тронулся и совсем скоро и Django'вский дефолтный тест раннер будет иметь поддержку автоматического поиска тестов в проекте и мы наконец забудем про from test_* import * как про страшный сон.

Само решение и соответствующий тикет появились довольно давно, а вчера Яннис Лейдл (jezdez, один из Django core-team) оформил решение как отдельный пакет, назвав его django-discover-runner. Шаг в верную сторону, но для меня до сих пор не понятно, почему это очевидное изменение не было сделано сразу после включения unittest2 в проект.

Постоянные сессии во Flask'е, один из способов

2012-05-17T01:09:00.000+03:00

По умолчанию, все содержимое flask.session будет очищено при закрытии браузера. Однако много когда нам нужно, чтоб данные сессии хранились и после рестарта браузера. Для этих случаев есть аттрибут permanent и следующий простой сниппет:

import datetime

from flask import Flask, session


app = Flask(__name__)
app.before_request(lambda: setattr(session, 'permanent', True))
app.permanent_session_lifetime = datetime.timedelta(days=14)

Последняя строчка сниппета выставляет длину сессии в 14 дней, во Flask'е же по дефолту используется 31 день для хранения постоянной сессии. Также эту настройку можно указать как PERMANENT_SESSION_LIFETIME в вашем settings.py.

зы. Однако также не забывайте, что Flask хранит все данные сессии в кукисах, а не как, например, Django только ключ сессии, а все данные уже считывает с базы данных или другого источника. Так что уместно будет использовать flask.session как хранилище каких-то ключей, например, токена текущего залогинненого пользователя.

Окончательно дружим Flask и nosetests

2012-05-02T12:52:00.000+03:00

Не секрет, что Flask и так хорошо дружит с nosetests, но до сегодняшнего дня был один очень раздражющий момент в их взаимоотношениях :)

Как мы все знаем nosetests по дефолту захватывает все из stdout/stderr и логгинга, чтоб при запуске тестов вывод не засорялся ненужной нам информацией. Однако в дебаг-моде Flask кладет на всех и устанавливает с помощью flask.logging.create_logger функции хэндлер, который начинает срать в консоль при каждом удобном случае, причем минуя все ранее установленные хэндлеры. Итог: куча ненужной логгинг информации при запуске тестов как:

(env)$ TESTING=1 nosetets -c -v -w <package>

Не хорошо, но In mock we trust, так что все что надо - это замокать упомянутую выше функцию в случае, когда мы запускаем тесты в дебаг-моде:

if TESTING and DEBUG:
    from flask import logging as flask_logging

    def mock_create_logger(app):
        return logging.getLogger(app.logger_name)

    flask_logging.create_logger = mock_create_logger

Помещаем этот сниппет в settings.py, затем не забываем загрузить настройки как import settings; app.config.from_object(settings) в нашем app.py - и получаем счастье, nosetests уверенно захватывает все нужное и вывод тестов чист и аккуратен.

Полный гист доступен на Гитхабе, если кто-то готов предложить более красивый вариант решения проблемы - жду в комментариях.

Flask-Dropbox

2012-04-21T12:17:00.000+03:00

За что нравится Flask, так это за его концепцию reusable apps. По сравнению с Django на создание по настоящему реюзабельного приложения уходит КУДА меньше времени.

Вот, например, вчера вечером захотелось поиграться с Dropbox API, а сегодня уже готов Flask-Dropbox :) Причем готов с тестовым проектом, который позволит вам загружать файлы в Dropbox, просматривать их и удалять.

Пример использования как всегда прост и неказист: импортируем главный класс и блюпринт, инициализируем их, регистрируем блюпринт с указанием префикса для урлов:

from flask import Flask
from flask.ext.dropbox import Dropbox, DropboxBlueprint

import settings


app = Flask(__name__)
app.config.from_object(settings)

dropbox = Dropbox(app)
dropbox_blueprint = DropboxBlueprint(dropbox)
app.register_blueprint(dropbox_blueprint, url_prefix='/dropbox')

Единственное на чем следует детально остановится - это настройки. Так как мы имеем дело с API, без них никуда :)

Во-первых, обязательно нужно будет настроить app.secret_key или просто SECRET_KEY, чтобы иметь возможность использовать flask.session (там будут храниться нужные нам токены).

Во-вторых, нужно будет создать какое-то приложение в Dropbox developers site, если еще нет такого и получить там DROPBOX_KEY, DROPBOX_SECRET и DROPBOX_ACCESS_TYPE. Без указания этих значений - кина не будет и Dropbox(app) отдаст вам ValueError :)

После укзания настроек все просто :)

Аутентификация. dropbox.is_authenticated проверит нет ли валидного access token'а в текущей сессии, dropbox.login_url сгенерирует урл для логина при помощи Dropbox, и наконец dropbox.logout_url отдаст урл, переход по которому вылогинит дропбокс пользователя. После успешного логина получить данные о пользователе можно из словаря dropbox.account_info.

Работа с дропбоксом. После того, как пользователь залогинился вся работа с его дропбоксом будет проходить через проперти dropbox.client, который является прокси к инициализированному инстансу DropboxClient. Полный список доступных методов последнего доступен в документации.

В остальном код доступен на ГитХабе, установить можно с PyPI. Пользуйтесь!

Flask-LazyViews

2012-04-03T20:44:00.000+03:00

Мне не нравится использовать декоратор @app.route или метод app.add_url_route для регистрации функций отображения во Flask приложениях и блюпринтах, потому что мне намного больше по душе паттерн ленивой загрузки этих функций :)

Именно так и родился Flask-LazyViews. Пример использования тривиальный, для приложений:

from flask import Flask
from flask.ext.lazyviews import LazyViews


app = Flask(__name__)
views = LazyViews(app)

views.add('/', 'views.home')
views.add('/page/', 'views.page')

Или для блюпринтов:

from flask import Blueprint
from flask.ext.lazyviews import LazyViews


blueprint = Blueprint('test', __name__)
views = LazyViews(blueprint, '.views')

views.add('/', 'test')
views.add('/advanced', 'advanced_test', methods=('GET', 'POST'))

Больше информации доступно как всегда на ГитХабе, установить можно с PyPI.

Flask-And-Redis

2012-03-12T10:36:00.000+02:00

Понадобилось на днях во Flask проекте докрутить поддержку Redis'а. Плюс, хотелось иметь возможность задавать любые настройки в settings модуле, в итоге появился Flask-And-Redis, так как в Flaks-Redis далеко не все можно настроить и оно не Flask-way инициализируется.

Пример использования есть в репозитории, по быстрому повторю и здесь:

from flask import Flask
from flask.ext.redis import Redis


app = Flask(__name__)
redis = Redis(app)

Вуаля :)