Об одной изящной задаче

Если немного схитрить в том, что это всё же не чисто математическая задача, а задание на программирование, то можно и в один вызов, сохраняя все исходные требования к типам:

class MyInt(int):
    memory: list[tuple] = []

    def __rmul__(self, __value):
        return MyInt(__value)

    def __add__(self, __value):
        self.memory.append((self, __value))
        return MyInt(0)


def magic(x: int, y: int, z: int) -> int:
    a = 314
    b = 271828
    c = 69
    return a * x + b * y + c * z


if __name__ == '__main__':
    x_ = MyInt(0)
    y_ = MyInt(0)
    z_ = MyInt(0)
    assert isinstance(x_, int)
    assert isinstance(y_, int)
    assert isinstance(z_, int)

    result = magic(x=x_, y=y_, z=z_)
    assert isinstance(result, int)
    print(', '.join([str(j) for i in result.memory for j in i if j]))

Можно изящнее, но подход, думаю, понятен

Валидируйте это немедленно

Парсинг — это, скорее, нечто простое: например, проверка, что полученная строка выглядит как ожидаемое число. В обозреваемых библиотеках уже начинается некоторая логика: например, проверить, что значение в поле age больше 21, где 21 взято из конфига сервиса. Или сказать, что карты Visa мы не поддерживаем, прочитав значение из поля card_number. Или удостовериться, что значение в поле country/currency соответствует ISO. Так же там можно выполнять косметические трансформации данных: например, приводить email к нижнему регистру

Если же у нас проверки, затрагивающие базу, то их лучше выполнять не на уровне со views, а на уровне с services (где бизнес-логика). Потому что там уже есть коннекшн к базе, плюс там и так будут какие-то манипуляции с базой: например, сначала проверить на существование, а потом создать новую сущность. Т.о., как по мне, вся эта часть уже вне скоупа рассматриваемых библиотек для валидации, это уже является бизнес логикой

Пункт про "валидация только при изменении" не уверен, что понял корректно. Если суть в том, что мы добавили какие-то правила на выходную схему, а миграцию данных в базе не провели, поэтому старые данные могут всё сломать, то так не надо делать :) Сначала вешаем ограничение на входные данные (чтобы в базе не прибавлялось чего-то невалидного), потом чистим значения в базе, и лишь потом включаем ограничения на выходные данные

С локализацией ошибок вроде можно довольно просто: бек отвечает, например, кодом ошибки и текстом в определенном формате, а фронт уже переводит в человекочитабельный вид, с учетом локали юзера. Если же не хотим забивать память фронта локализациями, то можно проворачивать эту конвертацию текста ошибки на беке в специальной middleware

Соглашусь, что правильная обработка ошибок и предоставление обратной связи пользователю — непростая тема. Порой от сообщения "что-то пошло не так, попробуйте еще раз" хочется пожать авторам горло

Валидируйте это немедленно

Всё так. И это удивительно: trafaret, написанный на python, почти догоняет pydantic, который на rust. При этом первый ещё и выпускает по одному обновлению в год, а второй релизится раза по два каждый месяц

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