Python v3.x: обработчик исключений для корутин и синхронных функций. Вобщем, для всего

[worldmind]

ээ, я ожидал презентацию декоратора, кишки это уже дело второе

[ivanuzzo]

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

[worldmind]

А какую проблему он решает?

[ivanuzzo]

избавляет от необходимости везде писать try...except, что само по себе достаточно громоздко. Делает код компактным и избавляет от необходимости его дублирования.

[worldmind]

Так нигде и не надо писать try..except — подавляющее большинство исключений должно обрабатываться на самом верхнем уровне, на то они и исключения, и декоратор там не поможет ничем.
А для типовых задач вроде повторения запроса к внешней системе есть типовые модули.

[ivanuzzo]

А как такой подход применить, если есть, например, сервер, который все запросы отдает в хэндлеры, а хэндлер может вернуть разный результат? Например, мы отправляем запрос на создание персонажа, а введенное имя уже занято. Получается, мне нужно добавить доп. запрос в бд на проверку имени, чтоб не использовать локально try except? Имхо, немного накладно. А с декоратором и локальным try...except мы в случае IntegrityError ('name' is duplicated) не делаем экстра запросов. Запрос всегда один.

[mayorovp]

В данном случае тот код, который занимается обработкой непосредственно запроса и передачей его в хендлер, и есть тот самый "верхний уровень".

[ivanuzzo]

правильно. И вот если не использовать локальный try except, то придется каждый раз делать еще один запрос в бд на уникальность. Полагаю, это не лучший вариант.

[mayorovp]

А, вот вы о чём. Но зачем вам тогда декоратор?

[ivanuzzo]

Затем, что таких try except очень много накапливается, они получаются более громоздкими, чем декоратор.

[mayorovp]

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

[ivanuzzo]

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

[worldmind]

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

[resetme]

айти-Маяковский всегда должен укладывается в 80 символов в строке… А то в печать не примут.

[ivanuzzo]

А у меня в PyCharm стандартные 120. По некоторым данным, это читабельнее. Так что, может, есть шанс попасть в печать?

[resetme]

Если бы было так, тот PEP-8 бы объявили устаревшим и выпустили новый.

Источник изложил свое субъективное мнение, а мое субъективное мнение в том что надо выгонять из команд людей не умеющих писать читаемый код в 80 символов. Больше 80 символов — это проявление неуважения к коллегам.

И конечно же трехколоночный мердж с длиной в 120 эта адская боль. Кто мерджил, тот поймет.

[ivanuzzo]

Справедливости ради, в PEP-8 также прописано следующее:

Some teams strongly prefer a longer line length. For code maintained exclusively or primarily by a team that can reach agreement on this issue, it is okay to increase the line length limit up to 99 characters, provided that comments and docstrings are still wrapped at 72 characters.

[resetme]

Умеющий писать код в 80 символов строки легко уместит и в 99.

Я помню случай, когда один программист попросил сделать в команде 100 длину строки, через неделю он уже попросил 120, а еще через неделю и этого стало мало. Он давал названия функций в 86 символов, а перевод строки вообще не считал нужным делать. При этом он считал себя чертовки хорошим программистом.

После двух десятков китайских предупреждений, его уволили, а строку вернули к 80 символам. Пока я переформатировал и переименовывал его функции, я нашёл с более десятка ошибок и некоторые критичные, которые были совершены при записи в одну строку. Он просто скрывал в длинных строках проблемы в алгоритмах, никто толком не мог разобрать его криво оформленный код и ему это сходило с рук.

Вообще при работе с профессиональными и сильными разработчиками никогда не встает вопрос о том какую длину строки выбрать в команде. Все легко умещают в 80 строк.

[ivanuzzo]

Вообще, как правило, любые правки в линтерах, общих конфигах и т.д. выносятся на обсуждение в команде. Если у всех с текущими настройками все ок (например, длина строки 80 символов всех устраивает), а одному почему-то не ок — значит надо разбираться в самом начале с этим специалистом, почему так. Ситуация, которую вы описали, может возникать в компаниях с высокой текучкой и в аутсорсе иногда и говорит она о том, что рабочий процесс не отлажен.

[resetme]

В этом случае процесс был более-менее отлажен, этого человека просто терпели, так как понимали что если уволят, то его работа ляжет на плечи других, а нового программиста вводить в курс дела это месяца на 2-3 растянется.

В нормальной команде никто не будет обсуждать длину строки. Есть более важные темы для обсуждения, а 80 символов всех устраивает.

[Mogost]

Нужно только помнить что такой декоратор даст довольно серьезный overhead при исполнении. На примере класса Math() из текста.

Сравнивая с реализацией try внутри метода

class MathWithTry(object):
    def divide(self, a, b):
        try:
            return a // b
        except ZeroDivisionError:
            return 'Делить на ноль нельзя, но можно умножить'

%timeit m_with_try.divide(1, 0)
406 ns ± 32.4 ns per loop (mean ± std. dev. of 7 runs, 1000000 loops each)

%timeit m_with_decorator.divide(1, 0)
3 µs ± 394 ns per loop (mean ± std. dev. of 7 runs, 100000 loops each)

Рост в 7 раз.

[ivanuzzo]

Есть такой момент. Я попробую поэкспериментировать, возможно, смогу оптимизировать. Благодарю за замечание.

[ivanuzzo]

Вот, что получилось.