Как сохранить результат парсинга в валидаторе WTForms

Разбираем, как в WTForms и Flask избежать двойного парсинга: сохранять результат в поле, учитывать статическую типизацию и альтернативы через cache. Примеры.

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

Как воспроизвести проблему

Суть проста: валидатор парсит и выбрасывает результат, затем представление повторно парсит ту же строку.

def payload_checker(form, fld):
    try:
        # первый вызов парсера; результат выбрасывается
        parsed = parse_payload(fld.data)
    except Exception as exc:
        raise ValidationError(f"Invalid data: {exc}") from None

class PayloadForm(FlaskForm):
    payload = wtf.fields.StringField('Enter data', validators=[payload_checker])
    ...

@app.post('/some/url')
def submit_handler():
    frm = PayloadForm()
    if frm.validate_on_submit():
        # второй вызов парсера
        parsed = parse_payload(frm.payload.data)
    ...

Что на самом деле происходит

Валидация уже доказала, что данные можно разобрать, но так как результат нигде не хранится, код вынужден повторять работу, чтобы его получить. Это и расточительно, и рискованно с точки зрения ошибок. Ситуация — наглядный пример практичности Python: динамические объекты позволяют хранить контекст прямо там, где он нужен.

Прагматичное решение: сохранить разобранное значение в самом поле

Самый прямой ход — прикрепить разобранный результат к экземпляру поля во время валидации и затем считать его позже. Это соответствует принципу «Хотя практичность важнее чистоты.» и сохраняет простой поток выполнения.

def payload_checker(form, fld):
    try:
        parsed = parse_payload(fld.data)
    except Exception as exc:
        raise ValidationError(f"Invalid data: {exc}") from None
    # сохраняем значение для последующего использования
    fld.parsed_obj = parsed  # можно указать проверяющему типы проигнорировать это

class PayloadForm(FlaskForm):
    payload = wtf.fields.StringField('Enter data', validators=[payload_checker])
    ...

@app.post('/some/url')
def submit_handler():
    frm = PayloadForm()
    if frm.validate_on_submit():
        parsed = frm.payload.parsed_obj  # получаем без повторного парсинга
        ...

Такой подход использует динамическую природу Python с минимальными формальностями. Но есть практическая оговорка: конфликт имен. Атрибуты, добавленные на лету, могут пересечься с существующими, а коллизии — более широкая и недооценённая проблема объектной модели Python. Помогает выбрать имя атрибута, маловероятно пересекающееся с внутренностями библиотеки; было бы удобно, если бы библиотеки резервировали префикс для таких расширений.

Нюансы статической типизации

Если в проекте используется статическая проверка типов, ожидайте жалоб как при присвоении нового атрибута объекту из библиотеки, так и при последующем чтении. Статическая проверка плохо сочетается с динамическим расширением объектов. На практике можно попросить проверяющий инструмент игнорировать и присвоение, и чтения, либо применять typing.cast при чтении, чтобы проверка признала существование атрибута. Другой путь — привести к отдельно аннотированному классу поля, где дополнительный атрибут объявлен.

Альтернативы, если вам ближе кэширование

Бывают сценарии, где второй вызов функции можно оставить, но избежать повторных вычислений. Один вариант — пометить функцию парсинга как кэшируемую через functools.cache. В коде по‑прежнему будет два вызова, но второй возьмёт результат из кэша, а не запустит парсер заново. Это работает, если вход парсера хэшируемый; здесь валидатор передает парсеру fld.data, а для StringField это строка и, следовательно, хэшируема.

from functools import cache

@cache
def parse_payload(text):
    ...  # та же логика парсинга, что и раньше

Ещё один подход — построить кэш самостоятельно, например через contextvars.ContextVar. Это сложнее, но с некоторых точек зрения выглядит более «правильным», чем привязывать атрибуты к экземплярам полей. Кэш также может помогать между разными запросами, когда это уместно.

Почему это важно

Устранение двойного парсинга убирает лишнюю работу, уплотняет обработку запроса и снижает риск тонких несоответствий. Хранение разобранного значения вместе с полем — решение явное и локальное, а кэширование предлагает иной компромисс: сохраняются «чистые» интерфейсы ценой дополнительного уровня опосредования.

Выводы

Если валидатор WTForms уже парсит значение, сохраните результат. Привязка его к экземпляру поля — взвешенный, идиоматичный для Python подход, при условии внимательного выбора имени атрибута, чтобы избежать коллизий. При статической типизации подавляйте предупреждения там, где это уместно, или используйте приведение типов. Если вам ближе неизменяемость объектов, кэшируемый парсер устранит повторные вычисления, тем более что входная строка хэшируема. Выбирайте путь, соответствующий стилю и ограничениям вашего проекта, но в первую очередь оптимизируйте ясность и согласованность.