Comments 4
Здорово)
Хочется поговорить о первом же примере, который в аннотации к статье.
Если написать:
… то всё выглядит не так уж страшно. В роскошном примере с применением Thunderargs… А что если operator будет, скажем, точкой? KeyError?
Удачи с проектом и больших цифр установки :)
Хочется поговорить о первом же примере, который в аннотации к статье.
Если написать:
@app.route('/calc/<int:x><op_key><int:y>')
def ugly_calc(x, op_key, y):
return str(OPERATION.get(op_key, plus)(x, y))
… то всё выглядит не так уж страшно. В роскошном примере с применением Thunderargs… А что если operator будет, скажем, точкой? KeyError?
Удачи с проектом и больших цифр установки :)
Если вы делаете, например, рестфул-интерфейс, то использовать url-обработчики не выйдет. Ну или если просто форма с большим числом данных. Да даже данные из формы авторизации передавать в url-е — очень дурной тон ( не считая http base auth).
>А что если operator будет, скажем, точкой? KeyError?
Ага. И мне это кажется логичным. Используй оператор из числа предоставленных, или получи ошибку. Другой вопрос что неплохо бы повесить туда какую-то более красивую и понятную для конечного пользователя ошибку. Может, сделать автоматический навес валидатора val_in для аргументов, у которых в качестве экспандера идёт словарь. В общем, тут тоже можно придумать что-нибудь.
Спасибо за замечения.
>А что если operator будет, скажем, точкой? KeyError?
Ага. И мне это кажется логичным. Используй оператор из числа предоставленных, или получи ошибку. Другой вопрос что неплохо бы повесить туда какую-то более красивую и понятную для конечного пользователя ошибку. Может, сделать автоматический навес валидатора val_in для аргументов, у которых в качестве экспандера идёт словарь. В общем, тут тоже можно придумать что-нибудь.
Спасибо за замечения.
Не понял, чем этот подход лучше WTForms?
Раз уж в третьем питоне есть специальные синтаксические конструкции для описания переменных, то почему бы ими не пользоваться?
Ну и есть ещё всякие мелочи. Например, у Endpoint из thunderargs нет жёсткой привязки к источнику данных. То есть можно вызывать ту же функцию calc из первого примера напрямую, из кода. При этом все проверки и приведения будут работать исправно.
Кроме того, чистая библиотека thunderargs годится для валидации аргументов не только на веб-серверах, но и вообще в любых функциях. Это может пригодиться, например, при написании точек входа какой-либо библиотеки, которую потом отдашь в общее пользование. Пример такой функции был в предыдущей статье.
В общем, я выбрал для демонстрации именно веб-сервер только потому что сейчас это лежит в области моих интересов. Да и с работой более-менее коррелирует.
Ну а вообще, да, в плане веба существенных преимуществ переход с wtforms на эту сырую шнягу не даст. Может быть, сделает код чуть читабелней, да и всё. И то это дело вкуса.
Ну и есть ещё всякие мелочи. Например, у Endpoint из thunderargs нет жёсткой привязки к источнику данных. То есть можно вызывать ту же функцию calc из первого примера напрямую, из кода. При этом все проверки и приведения будут работать исправно.
Кроме того, чистая библиотека thunderargs годится для валидации аргументов не только на веб-серверах, но и вообще в любых функциях. Это может пригодиться, например, при написании точек входа какой-либо библиотеки, которую потом отдашь в общее пользование. Пример такой функции был в предыдущей статье.
В общем, я выбрал для демонстрации именно веб-сервер только потому что сейчас это лежит в области моих интересов. Да и с работой более-менее коррелирует.
Ну а вообще, да, в плане веба существенных преимуществ переход с wtforms на эту сырую шнягу не даст. Может быть, сделает код чуть читабелней, да и всё. И то это дело вкуса.
Sign up to leave a comment.
Thunderargs: практика использования. Часть 2