И за микрофон отдельный респект. В отличии от многих видео, которые записываются в дешманскую гарнитуру, Ваши смотреть, одно удовольствие. Это я Вам как звукорежиссёр в прошлом (15 лет стажа) говорю ))
12:08 def some_func(a=None, b=None): assert a or b Не сказал бы, что "эта конструкция проверит, что заданы либо a, либо b". Если я вызову, например, some_func(0, ""), то я задам значения для обоих параметров и при этом все равно получу Exception.
@@t0digital 90% информации ищу и смотрю сразу на английском, но русскоязычные ютьюберы как-то гораздо лучше объясняют всякое техническое/IT. Очень приятно на самом деле находить такой качественный контент именно на русском! Да будет шириться наше славное python-сообщество!
Спасибо огромное за видео, как всегда очень интересно!) Было бы очень интересно послушать про авторизацию, аутентификацию на примере джанго, какие преймущества разных способов (JWT, Session Authentication и тд)
Просьба записать видео о лайфхаках и всяких полезных штуках и хороших практиках в питоне (как делать что-то правильно). Например, использовать не конкатенацию строк а f-strings, и т.д)
7:01 KeyboardInterrupt наследуется от BaseException, соответственно, как сказано в видео, одним Exception'ом всё не отловить. Ссылка на документацию: docs.python.org/3/library/exceptions.html#KeyboardInterrupt И немного демонстрации: >>> BaseException.__bases__ (,) >>> Exception.__bases__ (,) >>> BaseException.__subclasses__() [, , , ]
23:32 Столкнулся с проблемой при обработке исключений, на уровне функции класса перехватить исключение получается, но на уровне функции main нет, сообщения отправляются в консоль и программа продолжает работать, например исключение ConnectionError модуля requests.
Алексей, добрый день, в первую очередь хотел бы выразить Вам огромное спасибо за ваш труд. Ваш контент просто супер. Как будет у вас свободное время, можете запилить REST API на DRF? Я думаю многим было бы это очень интересно. Еще раз спасибо!
ахах, под такую музыку надо томным голосом говорить... "твой код самый лучший"... "у тебя не бывает не обработанных исключений".... "у тебя всегда всё компилится с первого раза"... "чак норис восхищается твоим кодом".... ЗЫ спасибо за ролик))
Как всегда отличное видео, проясняющее не очень ясные моменты. Лутц достаточно туманно на мой взгляд высказался в плане рекомендаций по использованию исключений. Спасибо, что разложил по полочкам.
Спасибо! А какие возникают накладные расходы при использовании исключений? Если обработка их реализована в коде, но они не срабатывают (то есть, код правильный, работает правильно), то влечёт ли это замедление исполнения? Дополнительное использование памяти? Насколько и когда стоит обращать на это внимание (если есть накладные расходы)?
Просьба записать видео о том, как быстро разбираться в коде уже существующего проекта. Вот посадили новичка на проект, а там куча файлов и папок, множество встроенных друг в друга функций и так далее. Как распутывать этот клубок? С чего начинать изучение чужого кода? Возможно, есть какие-то приемы картирования кода проекта? Хотелось бы такой контент.
Этот вопрос решает документация к проекту. Не многотомная устаревшая фигня, а несколько страничек с описанием структуры проекта, архитектуры и решаемых задач. По нему человек уже может вникнуть быстрее, что к чему. Ну и живое общение никто не отменял, после ознакомления с кодом и документацией можно пообщаться с новичком, ответить на вопросы и тд, живое общение очень полезно.
Привет. Спасибо за видео. Оффтопик - зачем Вы каждый раз выходите из vim что бы запустить приложение? :) :!python % либо добавить hotkey :nmap :!python %
ImportError - отличная штука для нестандартных модулей (можно после except выдать диагностику, что нужно сделать, чтобы модуль появился) и для создания кода, совместимого с Python 2.
Как же "Better is ask forgiveness, than permission"?))) (По поводу try-except vs if-else). Интересный кейс по поводу скорости обработки и затрат ресурсов. Есть доказательства? хотелось бы проверить) Спасибо за контент, зашёл отлично )
Здравствуйте Алекскей! К сожаленю я не мог попасть на стримы, но у меня к вам есть вопрос касательно немного другой темы. Когда я использую typehintings, как мне указать, что в качестве переменной должна быть функция или или класс. В документации нашел только object. Значит ли это то, что для решения моей проблемы надо указывать object? Заранее спасибо
Привет! from typing import Callable - это тип для функции, для класса тип type. То есть хинт для функции some_func: Callable, для класса (если это прям любой-любой класс) - some_class: type.
Здравствуйте. Начал изучать python, и не совсем понимаю: когда именно нужно пользоваться исключениями, если практически все можно проверить конструкцией "if-else"? Можно ли совсем обойтись без обработки исключений?
В моём понимании. Всё то, что нельзя обнаружиться сразу, надо ловить, когда будет падать. Т.е., например, при запросе на сервер можно структуру body неплохо так прошерстить по трафарету, а не пускать дальше и ждать, упадёт не упадёт. Но бывают ситуации, где на берегу сразу не разберёшься.
@Диджитализируй! Спасибо за труд. Есть такая ситуация. В одном куске кода несколько вызовов разных функций : foo1(), foo2(), .... fooN() . Каждый из которых может бросить исключение: FooError1, FooError2, FooErrorN. Верно ли понимаю, что лучше написать отдельные функции, которые вызывают эти функции, обрабатывают эти исключения, а уж эти отдельные функции без обработки исключений можно вызвать в основной "собирающей" функции? {code} def foo1_safe(): try: foo1() except FooError1: pass def foo2_safe(): try: foo2() except FooError2: pass def fooN_safe(): try: fooN() except FooErrorN: pass def foo(): foo1_safe() foo2_safe() .... fooN_safe() {code} Именно так по python way ?
Спасибо за видео. Как всегда все круто. Но вот утверждение, что exception более ресурсоемко чем if..else заставило меня задуматься. Я не один раз и не от одного человека слышал, что в Python исключения ничего не стоят и дешевле кинуть исключение, чем делать if...else. Что-то сильно изменилось в этом плане со времён Python2? Или меня изначально ввели в заблуждение. Хотелось бы подробностей. С заменой исключений на if...else правильно замечено, что если всё-таки не удалось завершить операцию, то исключение нужно кинуть. А то были прецеденты когда проект становился похожим на PHP 😅
@@t0digital На мой взгляд в видео получилось немного неоднозначно про if-else vs. try-catch. Нельзя забывать про подход "Easier to ask for forgiveness than permission". Вот тут есть отличный ответ на эту тему: stackoverflow.com/a/7604717 Он дополняет пример из ссылки, которую вы привели.
изначально во главу угла ставится читабельность и поддержка кода. Есть случаи, когда try..except намного выразительнее, чем if..else. Лучше сэкономить десятки минут на разбор кода, чем микросекунду на его исполнение. Так что сильно заморачиваться по этому поводу не стоит.
"Исключения дорогие". Да, для обработки исключений создается отдельный стек либо специальные элементы стекфрейма. Исключения дают рантайм-оверхед, даже если ни одного исключения в вашей программе не произойдет, поскольку эти самые элементы стекфрейма нужно создать, а потом освободить. Это одна из причин, почему системный код даже сейчас пишется на C, или в крайнем случае на C++ с отключенными исключениями. "Языки программирования без исключений". В первую очередь это, конечно, C. Также могу добавить Rust, прилично в нем работал, там своеобразный подход к обработке исключительных ситуаций, и можно обойтись без кучи if-ов для их обработки. Обычно пишешь "something.unwrap()" (самый ленивый вариант), "something.expect("ЧётоНеТо")" или просто "something?" (вопросительный знак прокидывает исключение вверх по стеку вызовов, лишь бы возвращаемый тип соответствовал).
Спасибо за видео. Музыка заднего фона какая-то пульсирующая и иногда звучит достаточно громко и отвлекает. Не могу сказать, что в тишине лучше - дело вкуса, но если можно сделать уровень фона тише - будет здорово ))
Самый интерес-то и не рассказан - нелинейность и освобождение ресурсов, проблемы получения неконсистентности. Очень бы хотелось услышать от Вас на конкретных "сложных" примерах.
12:00 *assert a or b проверит, что задана хотя бы "а" или хотя бы "b"...* Не проверит. Это же bool, куда влетит не только None, но и пустая коллекция (в том числе и строка), ноль, незапустившийся диапазон и, собственно, само False. Всё это -- не None и могло бы восприниматься как данные для обработки, мало ли. Тогда уже a is not None or b is not None (или a != None or b != None, хороший повод для холивара). 27:00 *если что-то можно решить при помощи if - else, то исключения не нужны* Вот тут прям респект))) Потому что "простое лучше, чем сложное" и городить пирамиду из классов и 100500 импортов там, где можно этого не делать -- это хорошо и правильно. Тут можно и отсылочку вбросить: _даже если код с кучей классов и импортов выглядит как "чистый")))_
Кстати только, что проверил скорость обработки ифов и try, и получилось, что try выигрывает по скорости если нет ошибок и причем затраты не такие уж и большие, 10ns на проход цикла.. Если писать код так, чтоб редко были ошибки и если есть сразу их исправлять, то получается исключения не такие уж и затратные. %%timeit for i in range(1000): try: a = b*b except: a = 1 50.5 µs ± 949 ns per loop (mean ± std. dev. of 7 runs, 10000 loops each) # b = 1 346 µs ± 3.12 µs per loop (mean ± std. dev. of 7 runs, 1000 loops each) # b = '1' %%timeit for i in range(1000): if type(b) == int: a = b*b else: a = 1 135 µs ± 2.18 µs per loop (mean ± std. dev. of 7 runs, 10000 loops each) # b = 1 110 µs ± 2.8 µs per loop (mean ± std. dev. of 7 runs, 10000 loops each) # b = '1'
Мне пхп в этом плане нравится.. там исключения логируются автоматом и поэтому экзепщином не пользовался.. а где понимал, что будет исключение ифы делал.. И еще что хорошо в пхп было, что там каждый раз скрипт запускается и все приложение из за этого не падает.. И правится это все на лету, просто заменой файла, без перезагрузки проекта. Вот интересно в питоне подобный стиль программирования можно сделать? Если каждый раз от nginx запускать скрипт, это будет дорого по времени? или может еще как нить?
@@alexjuly7097 вот как раз, за счет того, что отдельно запускается каждый раз, то можно не парится об исключениях как таковых.. а вылавливать ошибки в логах и править их и тогда получается более чистый код..
Я конечно вдамся в изотерику контентмейкерства, но мне кажется темп музыки должен коррелировать с голосом. За видос спасибо, всё было очень понятно и как всегда полезно. #лайкпередпросмотром
кстати, еще на стриме писали , что NotImplementedError сработает только когда этот метод у инстанса вызовут. А abc.ABC не даст создать экземпляр класса, наверное это все-таки поудобнее
большое спасибо за видео, ждем следующих выпусков с нетерпением! также хотелось бы больше узнать про тестирование в Django, буду очень благодарен за освещение этой обширной темы в будущем)
Классное видео! Но если честно не понимаю зачем вообще нужно использовать Exceptions, в каких ситуациях, если можно написать if else. Объясните пожалуйста
Скорее всего просто показывает warning на except: без указания конкретного типа исключения, да, как Дмитрий пишет. Это не ошибка, просто пичарм обращает внимание на то, что возможно стоит указать конкретный тип отлавливаемого исключения
Я на всех сетевых запросах в десктоп приложениях вешаю try, except, на случай, если нет инета или любое другое исключение, которое может возникнуть из-за чего-то, что не относится к данной системе (навернулся удаленный сервер, оборвалась сеть и т.п.) Правильно ли так делать?
Это нормально, главное там отлавливать именно сетевые ошибки, а не базовый Exception, чтобы случайно не захватить другие ошибки, не относящиеся к сетевым, и не приписать их к сетевым
@@t0digital да, над этим поработаю. Спасибо Вам за ценные уроки. Сейчас я отлавливаю базовый Exception, но сначала я пишу функционал, его гоняю и тестирую, а потом уже оборачиваю рабочий код в try ну и обрабатываю Exception. Теперь понимаю, что это как тестить принтами))
"Имеет смbIсл сделать через if-else" - this is a wrong statement. try/except will take more time than "if" ONLY when the exception is caught. This situation will occur each time exception happens. BUT "if" operation occurs EACH time your code is run. Hence, it will steal our performance time. That's why EAFP exists in the Python world.
И за микрофон отдельный респект. В отличии от многих видео, которые записываются в дешманскую гарнитуру, Ваши смотреть, одно удовольствие. Это я Вам как звукорежиссёр в прошлом (15 лет стажа) говорю ))
О, спасибо! Приятно получать такую обратную связь от специалиста!
А мне мелодия сильно мешает слушать.
Воу неужели реально видео каждый день
Огромное тебе спасибо за твою работу!!!!! Один из лучших каналов по Python!!!🤬👍
великолепный видос, дай бог здоровья таким учителям с безукоризненным детализированием уроков
Спасибо! Рад, что полезно
Блииин - вот за "останов" процесса - отдельный респект!
Суперполезно, спасибо!!
Молодчина, каждый день видео, вот это работа!)
12:08
def some_func(a=None, b=None):
assert a or b
Не сказал бы, что "эта конструкция проверит, что заданы либо a, либо b".
Если я вызову, например, some_func(0, ""), то я задам значения для обоих параметров и при этом все равно получу Exception.
Курс по django и его Rest Api, будет просто топ от тебя!
спасибо за контент))
Рад, что полезно!
Просто и понятно. Спасибо за очередной полезный ролик.
Я восхищаюсь качеством видео на канале!
Спасибо!
Спасибо! Рад, что нравится!
Спасибо,все знал. Кроме длительности обрабатывания исключений. Лайк)
блин, насколько же крутой канал. Супер полезная инфа, в какой-то момент я прям почуствовал, как мне в мозг наконец-то пришло осознание
Спасибо! 🙏
давно хотел разобраться в исключениях в python и за пол часа все как то яснее стало, спасибо!
Отлично, рад, что полезно!
Большое спасибо за такие подробные и наглядные разъяснения!
Рад, что полезно!
@@t0digital 90% информации ищу и смотрю сразу на английском, но русскоязычные ютьюберы как-то гораздо лучше объясняют всякое техническое/IT. Очень приятно на самом деле находить такой качественный контент именно на русском! Да будет шириться наше славное python-сообщество!
Йееее! Рад быть частью этого:)
Спасибо за урок, очень приятная подача под ambient, даже слегка расслабился и насладился новой информацией.
Спасибо! то что нужно) Было бы интересно про пайтон в сторону функционального программирования
Функциональщина в Питоне отстой (имхо)
о, расскажу!
andron wens функциональщина в принципе отстой
Как же много годного контента, продолжай!
Спасибо!
Держи 1000-й лайк, друг! Спасибо за твои видео!
Качество на высоте, и музыка затягивает на просмотр, как гипноз
Спасибо. Было бы интересно услышать, что происходит под капотом в питоне, когда бросается исключение
Хорошая идея для видео, спасибо
Здорово! Спасибо за всегда интересный и полезный контент!
Спасибо огромное за видео, как всегда очень интересно!) Было бы очень интересно послушать про авторизацию, аутентификацию на примере джанго, какие преймущества разных способов (JWT, Session Authentication и тд)
27:10 Так, только что посмотрел видео про EAFP и там говорилось, что лучше трай-ексепт делать, чем ифы. А тут наоборот
Круто получилось) Очень подробно и всесторонне представлена тема обработки исключений в Python. Буду использовать.
Алексей, большое спасибо за ваш труд :)
Спасибо! Как раз изучаю эту тему сейчас. Актуально👍
Ждал видос по этой теме! Крутой контент)
Юхууу! Спасибооо!
Интересные пол часа, спасибо!
Спасибо!
Молодчина, большое спасибо за видео
Спасибо за ролик!
Удивительно в кон,ваше видео. Желаю успехов!
Спасибо 🙏
Просьба записать видео о лайфхаках и всяких полезных штуках и хороших практиках в питоне (как делать что-то правильно). Например, использовать не конкатенацию строк а f-strings, и т.д)
Благодарю, отличный урок. Сейчас допиливать своё приложение буду, а то падает от каких- то внешних факторов.
Большое, Вам, спасибо! :)
Я еще не смотрел но наконец дождался))
Ура-ура!
7:01
KeyboardInterrupt наследуется от BaseException, соответственно, как сказано в видео, одним Exception'ом всё не отловить.
Ссылка на документацию:
docs.python.org/3/library/exceptions.html#KeyboardInterrupt
И немного демонстрации:
>>> BaseException.__bases__
(,)
>>> Exception.__bases__
(,)
>>> BaseException.__subclasses__()
[, , , ]
23:32 Столкнулся с проблемой при обработке исключений, на уровне функции класса перехватить исключение получается, но на уровне функции main нет, сообщения отправляются в консоль и программа продолжает работать, например исключение ConnectionError модуля requests.
Алексей, добрый день, в первую очередь хотел бы выразить Вам огромное спасибо за ваш труд. Ваш контент просто супер. Как будет у вас свободное время, можете запилить REST API на DRF? Я думаю многим было бы это очень интересно. Еще раз спасибо!
Спасибо! По DRF материал планируется, да
@@t0digital кстати да, сейчас почти в каждой вакансии DRF, даже на джуна
Диджитализируй! Спасибо большое! Буду ждать с нетерпением!
ахах, под такую музыку надо томным голосом говорить... "твой код самый лучший"... "у тебя не бывает не обработанных исключений".... "у тебя всегда всё компилится с первого раза"... "чак норис восхищается твоим кодом"....
ЗЫ спасибо за ролик))
Праздник каждый день!=) так держать)
Слишком полезно, чтобы быть. Спасибо за багаж знаний. Лайк репост и благодарность
Грузовик лайков разгружать куда, командир?
Было бы круто разгрузить здесь!
Просто лучший! Очень полезная информация. Тебе бы стримас провести вместе с Мурренганом, вообще топ будет!
Спасибо!
Как всегда концентрированная полезная инфа)
Очень полезный видос:)
Ну ты фигачишь как автомат. Каждый день новое видео - очень круто ᕙ( ͡° ͜ʖ ͡°)ᕗ
Как всегда отличное видео, проясняющее не очень ясные моменты. Лутц достаточно туманно на мой взгляд высказался в плане рекомендаций по использованию исключений. Спасибо, что разложил по полочкам.
Спасибо! А какие возникают накладные расходы при использовании исключений? Если обработка их реализована в коде, но они не срабатывают (то есть, код правильный, работает правильно), то влечёт ли это замедление исполнения? Дополнительное использование памяти? Насколько и когда стоит обращать на это внимание (если есть накладные расходы)?
Алексей, а можно что-нибудь про юниттесты еще? Однозначно лайк! :)
Да, планирую материал
Здравствуйте. Что думаете по поводу создания декораторов для обработки исключений?
Да, в каких-то сценариях можно и так
что лучше использовать и что быстрее сработает и что будет наглядней, декоратор проверки или все же try catch
Алексей, спасибо что чаще стали баловать нас подписчиков новыми видео. Фоновая музыка, мне кажется, только лишняя.
Да, похоже, что лучше без музыки
Просьба записать видео о том, как быстро разбираться в коде уже существующего проекта. Вот посадили новичка на проект, а там куча файлов и папок, множество встроенных друг в друга функций и так далее. Как распутывать этот клубок? С чего начинать изучение чужого кода? Возможно, есть какие-то приемы картирования кода проекта? Хотелось бы такой контент.
Этот вопрос решает документация к проекту. Не многотомная устаревшая фигня, а несколько страничек с описанием структуры проекта, архитектуры и решаемых задач. По нему человек уже может вникнуть быстрее, что к чему. Ну и живое общение никто не отменял, после ознакомления с кодом и документацией можно пообщаться с новичком, ответить на вопросы и тд, живое общение очень полезно.
Привет.
Спасибо за видео.
Оффтопик - зачем Вы каждый раз выходите из vim что бы запустить приложение? :)
:!python %
либо добавить hotkey
:nmap :!python %
привычка:)
Спасибо за контент! Просьба - делать фоновую музыку потише, иногда она выходит на громкость почти равную голосу и это отвлекает от сути.
ImportError - отличная штука для нестандартных модулей (можно после except выдать диагностику, что нужно сделать, чтобы модуль появился) и для создания кода, совместимого с Python 2.
"AssertionError - забавная штука, не очень часто ее используют..." - кто-то спалился, что не пишет тесты)
а зачем тебе в тестах обрабатывать исключение?) тут уже наверное проблема в архитектуре раз тест может быть упавшим, но ... "неочень" :)
Фоновая музыка - это ужасно.
Благодарю за уроки, качественно и полезно!
Как же "Better is ask forgiveness, than permission"?))) (По поводу try-except vs if-else). Интересный кейс по поводу скорости обработки и затрат ресурсов. Есть доказательства? хотелось бы проверить)
Спасибо за контент, зашёл отлично )
Здравствуйте Алекскей! К сожаленю я не мог попасть на стримы, но у меня к вам есть вопрос касательно немного другой темы. Когда я использую typehintings, как мне указать, что в качестве переменной должна быть функция или или класс. В документации нашел только object. Значит ли это то, что для решения моей проблемы надо указывать object? Заранее спасибо
Привет! from typing import Callable - это тип для функции, для класса тип type.
То есть хинт для функции some_func: Callable, для класса (если это прям любой-любой класс) - some_class: type.
@@t0digital Большое спасибо
Спасибо. Можно ещё об api testing (pytest) рассказать?
Здравствуйте. Начал изучать python, и не совсем понимаю: когда именно нужно пользоваться исключениями, если практически все можно проверить конструкцией "if-else"? Можно ли совсем обойтись без обработки исключений?
tnx boss!
*Спасибо*
🙏
Офигенная фоновая музыка. Помедетировал. Спасибо😁
Отлично :) хотя понравилось не всем
В моём понимании. Всё то, что нельзя обнаружиться сразу, надо ловить, когда будет падать.
Т.е., например, при запросе на сервер можно структуру body неплохо так прошерстить по трафарету, а не пускать дальше и ждать, упадёт не упадёт.
Но бывают ситуации, где на берегу сразу не разберёшься.
Но также, наверное, следует выдерживать баланс, беря во внимание подход "Easier to ask for forgiveness than permission"
Спасибо!
Алексей, что за продуктивность?))
Нашёл трёхлитровую банку с кокаином! *шутка
Диджитализируй! Задонатили что ли? 😂
@@romarioyeah только тссс!
Диджитализируй! Могила 🤐
Спасибо за видео !!!
@Диджитализируй!
Спасибо за труд.
Есть такая ситуация. В одном куске кода несколько вызовов разных функций : foo1(), foo2(), .... fooN() . Каждый из которых может бросить исключение: FooError1, FooError2, FooErrorN.
Верно ли понимаю, что лучше написать отдельные функции, которые вызывают эти функции, обрабатывают эти исключения, а уж эти отдельные функции без обработки исключений можно вызвать в основной "собирающей" функции?
{code}
def foo1_safe():
try:
foo1()
except FooError1:
pass
def foo2_safe():
try:
foo2()
except FooError2:
pass
def fooN_safe():
try:
fooN()
except FooErrorN:
pass
def foo():
foo1_safe()
foo2_safe()
....
fooN_safe()
{code}
Именно так по python way ?
Спасибо за видео. Как всегда все круто. Но вот утверждение, что exception более ресурсоемко чем if..else заставило меня задуматься. Я не один раз и не от одного человека слышал, что в Python исключения ничего не стоят и дешевле кинуть исключение, чем делать if...else. Что-то сильно изменилось в этом плане со времён Python2? Или меня изначально ввели в заблуждение. Хотелось бы подробностей.
С заменой исключений на if...else правильно замечено, что если всё-таки не удалось завершить операцию, то исключение нужно кинуть. А то были прецеденты когда проект становился похожим на PHP 😅
Вот что об этом пишут на офсайте docs.python.org/3/faq/design.html#how-fast-are-exceptions
@@t0digital На мой взгляд в видео получилось немного неоднозначно про if-else vs. try-catch.
Нельзя забывать про подход "Easier to ask for forgiveness than permission".
Вот тут есть отличный ответ на эту тему: stackoverflow.com/a/7604717
Он дополняет пример из ссылки, которую вы привели.
изначально во главу угла ставится читабельность и поддержка кода. Есть случаи, когда try..except намного выразительнее, чем if..else. Лучше сэкономить десятки минут на разбор кода, чем микросекунду на его исполнение. Так что сильно заморачиваться по этому поводу не стоит.
лучший айти блог
Спасибо:) Стараемся!
"Исключения дорогие". Да, для обработки исключений создается отдельный стек либо специальные элементы стекфрейма. Исключения дают рантайм-оверхед, даже если ни одного исключения в вашей программе не произойдет, поскольку эти самые элементы стекфрейма нужно создать, а потом освободить. Это одна из причин, почему системный код даже сейчас пишется на C, или в крайнем случае на C++ с отключенными исключениями.
"Языки программирования без исключений". В первую очередь это, конечно, C. Также могу добавить Rust, прилично в нем работал, там своеобразный подход к обработке исключительных ситуаций, и можно обойтись без кучи if-ов для их обработки. Обычно пишешь "something.unwrap()" (самый ленивый вариант), "something.expect("ЧётоНеТо")" или просто "something?" (вопросительный знак прокидывает исключение вверх по стеку вызовов, лишь бы возвращаемый тип соответствовал).
24:33 отлов всех неотловленных ислючений
Спасибо за видео. Музыка заднего фона какая-то пульсирующая и иногда звучит достаточно громко и отвлекает. Не могу сказать, что в тишине лучше - дело вкуса, но если можно сделать уровень фона тише - будет здорово ))
Спасибо! Приму к сведению!
Спасибо за видео)
Кстати, в будущих версия Питона вроде как обещают что исключения не будут оказывать столь существенного влияния на скорость
а видосики по go не планируются? было бы круто если закодить в реалтайме что-то не сложное.
Планируются обязательно. Планов огромное количество. Время найти бы.
@@t0digital Я все хочу немного погрузиться в него, но как-то руки тоже не доходят. Будем ждать!
Самый интерес-то и не рассказан - нелинейность и освобождение ресурсов, проблемы получения неконсистентности. Очень бы хотелось услышать от Вас на конкретных "сложных" примерах.
24:03
как вы f1() и f2() перместили ровно на один таб,
я сам пользуюсь вимом, но не знаю про эту фичу
> или >> в зависимости от того, выделены ли сдвигаемые строки
@@t0digital работает! спасибо)
@@kriskaruzo1398 отлично :) с вимом можно постоянно находить новые фишки
На 2:15 минуте подвинулась кружка)
12:00 *assert a or b проверит, что задана хотя бы "а" или хотя бы "b"...*
Не проверит. Это же bool, куда влетит не только None, но и пустая коллекция (в том числе и строка), ноль, незапустившийся диапазон и, собственно, само False. Всё это -- не None и могло бы восприниматься как данные для обработки, мало ли. Тогда уже a is not None or b is not None (или a != None or b != None, хороший повод для холивара).
27:00 *если что-то можно решить при помощи if - else, то исключения не нужны*
Вот тут прям респект))) Потому что "простое лучше, чем сложное" и городить пирамиду из классов и 100500 импортов там, где можно этого не делать -- это хорошо и правильно. Тут можно и отсылочку вбросить: _даже если код с кучей классов и импортов выглядит как "чистый")))_
да, a or b, конечно, не проверяет именно на None
Как по мне нужно использовать исключения там где они элегантно вписываются и уменьшают затраты по ресурсам. Аля get or create в orm-ке
Кстати только, что проверил скорость обработки ифов и try, и получилось, что try выигрывает по скорости если нет ошибок и причем затраты не такие уж и большие, 10ns на проход цикла.. Если писать код так, чтоб редко были ошибки и если есть сразу их исправлять, то получается исключения не такие уж и затратные.
%%timeit
for i in range(1000):
try:
a = b*b
except:
a = 1
50.5 µs ± 949 ns per loop (mean ± std. dev. of 7 runs, 10000 loops each) # b = 1
346 µs ± 3.12 µs per loop (mean ± std. dev. of 7 runs, 1000 loops each) # b = '1'
%%timeit
for i in range(1000):
if type(b) == int:
a = b*b
else:
a = 1
135 µs ± 2.18 µs per loop (mean ± std. dev. of 7 runs, 10000 loops each) # b = 1
110 µs ± 2.8 µs per loop (mean ± std. dev. of 7 runs, 10000 loops each) # b = '1'
Так и есть, исключения надо использовать там, где они будут вызываться редко docs.python.org/3/faq/design.html#how-fast-are-exceptions
Прекрасное видео, но звук на фоне мешает
Мне пхп в этом плане нравится.. там исключения логируются автоматом и поэтому экзепщином не пользовался.. а где понимал, что будет исключение ифы делал..
И еще что хорошо в пхп было, что там каждый раз скрипт запускается и все приложение из за этого не падает.. И правится это все на лету, просто заменой файла, без перезагрузки проекта.
Вот интересно в питоне подобный стиль программирования можно сделать? Если каждый раз от nginx запускать скрипт, это будет дорого по времени? или может еще как нить?
Могу соврать, но ведь в пхп нет "всего приложения", каждый скрипт запускается интерпретатором отдельно?
@@alexjuly7097 вот как раз, за счет того, что отдельно запускается каждый раз, то можно не парится об исключениях как таковых.. а вылавливать ошибки в логах и править их и тогда получается более чистый код..
Я конечно вдамся в изотерику контентмейкерства, но мне кажется темп музыки должен коррелировать с голосом. За видос спасибо, всё было очень понятно и как всегда полезно. #лайкпередпросмотром
да, я еще совсем не постиг дзен подбора звукового сопровождения
Читал где-то, что по правилам нейминга лучше к названию кастомного исключения в конце приписывать Error, а не Exception
кстати, еще на стриме писали , что NotImplementedError сработает только когда этот метод у инстанса вызовут. А abc.ABC не даст создать экземпляр класса, наверное это все-таки поудобнее
Да, это не полный аналог abc
большое спасибо за видео, ждем следующих выпусков с нетерпением!
также хотелось бы больше узнать про тестирование в Django, буду очень благодарен за освещение этой обширной темы в будущем)
Спасибо! Возможно сделаем материал
Классное видео! Но если честно не понимаю зачем вообще нужно использовать Exceptions, в каких ситуациях, если можно написать if else. Объясните пожалуйста
Для отладки применять. А потом уже более детально писать код.
блин музыка на фоне под которую я работаю, получается мозг думает что работать нужно даже при просмотре отдыхающего видео))
Хорошие видео у вас. Вы похожи на доброго кота из мультфильма, это специально подобранный образ?)
Хахах, спасибо! Даже не знаю:)
шЫкарно! Больше питонячего кода!
Программа: сорри, блабла....
Юзер: ну да, ну да, пошел я на...
Pycharm "ругается" когда пишешь try-except. Что там нового в PEP? Простой try-except уже не актуален?
после Except указан тип исключения? Ловить всё - плохая примета.
Скорее всего просто показывает warning на except: без указания конкретного типа исключения, да, как Дмитрий пишет. Это не ошибка, просто пичарм обращает внимание на то, что возможно стоит указать конкретный тип отлавливаемого исключения
10:15 оно так-то и не ловится в try/except, его нельза обработать
Я на всех сетевых запросах в десктоп приложениях вешаю try, except, на случай, если нет инета или любое другое исключение, которое может возникнуть из-за чего-то, что не относится к данной системе (навернулся удаленный сервер, оборвалась сеть и т.п.)
Правильно ли так делать?
Это нормально, главное там отлавливать именно сетевые ошибки, а не базовый Exception, чтобы случайно не захватить другие ошибки, не относящиеся к сетевым, и не приписать их к сетевым
@@t0digital да, над этим поработаю. Спасибо Вам за ценные уроки. Сейчас я отлавливаю базовый Exception, но сначала я пишу функционал, его гоняю и тестирую, а потом уже оборачиваю рабочий код в try ну и обрабатываю Exception. Теперь понимаю, что это как тестить принтами))
А как же pep8 (суффикс Error у эксепшена под ошибку)? ;)
Салют 🎉 как бодрость духа ⁉️
"Имеет смbIсл сделать через if-else" - this is a wrong statement.
try/except will take more time than "if" ONLY when the exception is caught.
This situation will occur each time exception happens.
BUT "if" operation occurs EACH time your code is run. Hence, it will steal our performance time.
That's why EAFP exists in the Python world.
Дальше идёт поясняющей пример, который, как мне кажется, поясняет эту мысль. Если вырвать из контекста эту фразу, то да, она неверна.