validate methods (related to Specification and Definition classes) questions

[varnie]

Речь про метод vaildate в классе Дефиниции и Спецификации.
Открытые вопросы на обсуждение:

Как предполагается использовать методы validate в Спецификации и Дефиниции?

Как реагировать на невалидные данные: игнорировать и выбрасывать варнинг, падать, или еще каким-то образом?

Может быть вынести эту логическую часть во внешнюю сторону, т.к. сейчас опять придем примерно к той же ситуации, что была с классом Table (где объекты могут иметь невалидное состояние).

Можно завести т.н. Валидаторы, в которых реализовать всю эту логику, как для Спецификаций, так и для Дефиниций.

Плюс завернуть получение Спецификации и Дефиниций сразу в этот валидатор, который на выходе даст только валидные объекты и отрапортует о найденных проблемах.

Это на уровне идеи.

[epogrebnyak]

Вопросы: - Валидатор, что это: класс, функция? - Есть ли где-то реализованные примеры внутри каких-то - Где вызываются Валидаторы? Предлагаю в конце cfg.py + должны падать с описанием проблемы Нам грозит еще сделать список переменных со строкой описания в cfg.py - для фронпейдж.мд , его тоже надо валидировать, поэтому дело нужное. плюс внутренне поддерживаю на основании того, что валидации и сообщения об ошибках лучше держать отдельно от осноаного кода, потому что они ветвистые и страшные 8 июн. 2017 г. 3:52 ПП пользователь "varnie" <notifications@github.com> написал:

…

Речь про метод vaildate в классе Дефиниции и Спецификации. Открытые вопросы на обсуждение: Как предполагается использовать методы validate в Спецификации и Дефиниции? Как реагировать на невалидные данные: игнорировать и выбрасывать варнинг, падать, или еще каким-то образом? Может быть вынести эту логическую часть во внешнюю сторону, т.к. сейчас опять придем примерно к той же ситуации, что была с классом Table (где объекты могут иметь невалидное состояние). Можно завести т.н. Валидаторы, в которых реализовать всю эту логику, как для Спецификаций, так и для Дефиниций. Плюс завернуть получение Спецификации и Дефиниций сразу в этот валидатор, который на выходе даст только валидные объекты и отрапортует о найденных проблемах. Это на уровне идеи. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#15>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AI1grnuoHnrpEh5BN5_wVhDH74CxUlO1ks5sB-6bgaJpZM4N0Brt> .

[varnie]

Валидатор - это название подхода, имплементация может быть как ф-цией так и классом.
Примеров море, но пока что мне не на 100% понятно, какой следует выбрать подход, т.к. сперва нужно определиться с желаемым поведением (как я изложил выше): что делать с невалидными данными (дефиниции, спецификации), лучше бросить эксепшн на ранней стадии и как-то это зарегистрировать/отрапортовать об ошибке или отложить диагностику на дальнейший этап?

В самом простом случае подход через дескрипторы подойдет. Простейший пример представлен здесь:
https://www.codevoila.com/post/69/python-descriptors-example
начиная с параграфа "2.2 Use Python descriptor".

Есть еще тяжеловесный http://www.formencode.org/en/latest/Validator.html
, но тащить лишние зависимости не хочется.

Хотел бы напомнить, что мы хотим уйти от необходимости наличия методов validate в классах, тем самым избежать заведения "невалидных" объектов.

[epogrebnyak]

Some implementations at 027a92a

[epogrebnyak]

Посмотрите плс - получилось реализовать классы IsuueWarning и Check по parse.py.
Как классы они не особо симпатичные, но зато чище выглядят сами функции и методы, где они вызываются (нет всяких проверок), SILENT не маячит внутри кода. Наверное есть более профессиональные способы проверок, нопока так. Несколько исключений внутри кода осатлось (ERROR когда не находится заголовок) и что-то компактное.

[varnie]

Неочень понятна зона ответственности у класса Check и IssueWarning.
Вся разница в том что первый выдает эксепшн в случае найденных проблем (+ знает сам как искать проблемы), второй фактически просто обертка над print.
Грубо говоря Check - это "фатальная проверка", а IssueWarning - "нефатальный репорт" о проблеме.

Может быть не работать внешне с IssueWarning, а пусть все проверки (и нефатальные тоже) идут через класс Check,
а тот сам уже будет знать, как какую проблему рапортовать (выдавать эксепшн или печатать в консоль, используя IssueWarning)?

Скажем, сейчас в конструкторе Таблицы есть такое:

if self.coln not in self.VALID_ROW_LENGTHS:
               IssueWarning().bad_row_length(self)

Чем это словесно отличается от метода table_defined класса Check, кроме того что в table_defined отлавливаются фатальные ошибки, а в этих строках просто варнинг?

Понятнее было бы как-то так, в конструкторе Таблицы:
Check.table_has_valid_row_length(self)

Может выше непрозрачно написал; если перефразировать, то предлагаю сделать класс IssueWarning вспомогательным, который будет вызываться только из класса Check.