Спасибо! Думал, как же это обозвать? Вы подсказали - "по середине градиента" )) Вот и я приверженец этой середины. Не люблю try - except, но если есть ситуация, в которой им воспользоваться гораздо быстрее/проще, то вставляю эту конструкцию без проблем. Но чаще всё же это проверки и очень нравится у словарей метод .get() Хотелось бы, чтобы таких методов было побольше для разных сущностей
Многое ещё зависит от того, имеет ли смысл дальнейшее выполнение кода, если то или иное условие окажется вдруг невыполненным. Если дальнейшее выполнение функции представляется бессмысленным без искомого файла или ключа в словаре, и вам так или иначе придётся кидать исключение, тогда напрашивается использование EAFP. Если дальнейшее выполнение имеет смысл - тогда напрашивается использование LBYL.
живём одним моментом) вот нам сейчас нужен ключ, мы проверяем его наличие (lbyl), либо напрямую просим значение и ждём, что оно упадёт (eafp) - в обоих случаях возможно как дальнейшее выполнение кода, так и отказ от него, для lbyl это будет означать, например, выход из функции в операторе else, а для eafp это будет проброс нового исключения в блоке except (или просто выход из функции здесь же), то есть важно, что произошло сейчас, и какая инфраструктура это "сейчас" окружает в Python (и многих других языках) можно любую программу написать с помощью обоих подходов, как в чистом виде, так и с примесями одного в другой, это не вопрос логики работы самой программы, это вопрос читаемости, удобства и личных предпочтений в конце концов, то есть это именно методология - "как мы пишем красивый код", а не "как мы решаем конкретную задачу"
Редко использую try except, т.к. считаю такой подход несколько читерским. Он как бы освобождает разработчика от ответственности хорошо понимать свой код, и разрешает подставлять костыли, там где что-то сломалось.
Исключения - это не костыли, а часть контрактов, которые позволяют коду разных разработчиков взаимодействовать друг с другом. В своём собственном коде вы можете разбираться до посинения, а вот начинать разбираться в чужих классах только для того, чтобы провзаимодействовать с ними, - эпик фейл.
Блин, видосы и правда зачётные. Я пользуюсь eafp, но ифы тоже весьма уместны порой.
Отличные видео, спасибо!
стараемся)
Спасибо! Думал, как же это обозвать? Вы подсказали - "по середине градиента" )) Вот и я приверженец этой середины. Не люблю try - except, но если есть ситуация, в которой им воспользоваться гораздо быстрее/проще, то вставляю эту конструкцию без проблем. Но чаще всё же это проверки и очень нравится у словарей метод .get() Хотелось бы, чтобы таких методов было побольше для разных сущностей
удобнее пользоваться сразу всем, чем только чем-то одним))
Многое ещё зависит от того, имеет ли смысл дальнейшее выполнение кода, если то или иное условие окажется вдруг невыполненным. Если дальнейшее выполнение функции представляется бессмысленным без искомого файла или ключа в словаре, и вам так или иначе придётся кидать исключение, тогда напрашивается использование EAFP. Если дальнейшее выполнение имеет смысл - тогда напрашивается использование LBYL.
живём одним моментом) вот нам сейчас нужен ключ, мы проверяем его наличие (lbyl), либо напрямую просим значение и ждём, что оно упадёт (eafp) - в обоих случаях возможно как дальнейшее выполнение кода, так и отказ от него, для lbyl это будет означать, например, выход из функции в операторе else, а для eafp это будет проброс нового исключения в блоке except (или просто выход из функции здесь же), то есть важно, что произошло сейчас, и какая инфраструктура это "сейчас" окружает
в Python (и многих других языках) можно любую программу написать с помощью обоих подходов, как в чистом виде, так и с примесями одного в другой, это не вопрос логики работы самой программы, это вопрос читаемости, удобства и личных предпочтений в конце концов, то есть это именно методология - "как мы пишем красивый код", а не "как мы решаем конкретную задачу"
@@pythonclinic Хорошая читаемость кода несовместима с жизнью одним моментом )))
Редко использую try except, т.к. считаю такой подход несколько читерским. Он как бы освобождает разработчика от ответственности хорошо понимать свой код, и разрешает подставлять костыли, там где что-то сломалось.
А как насчёт настолько хорошего понимания своего кода, что мы заранее знаем, где какая ошибка упадёт, и сразу же их ловим?)))
Обработка ошибки, и понимание условий при которых возникает ошибка, это несколько разное понимание кода на мой взгляд.
Исключения - это не костыли, а часть контрактов, которые позволяют коду разных разработчиков взаимодействовать друг с другом. В своём собственном коде вы можете разбираться до посинения, а вот начинать разбираться в чужих классах только для того, чтобы провзаимодействовать с ними, - эпик фейл.