Спасибооо!

Ещё Олег Молчанов неплохо объяснял (давно у него роликов не было). И автор этого канала, на котором мы сейчас, безусловно - молодец!

@@user-oi1zl6de8i Да, как раз когда писал, Олег был на уме как и диджитализируй)

@@kalik54 Да, эти товарищи вносят существенный вклад в развитие python-сообщества в России и русскоговорящих странах.

@@user-oi1zl6de8i +. скорее он бы вернулся(

starlette и fastapi интереснее

@@rishatsharafiev aiohttp и asyncio интереснее

@@rishatsharafiev Асинхрон - концепт современного кодинга, это прям надо. Это есть в C++, C#, Python, Rust и вообще везде (правда, Java немного страдает), это надо изучать не только питоноидам.

А мне бы Sanic, сколько людей столько мнений))

@@MegaFeel1 хорошо, что фреймворков меньше))

@@avazart614 и не про чистоту кода, по всей видимости

спасибооо!

Да чем всех dict.get( ) не устраивает?

Спасибо!

Рад, что полезно:)

Скоро будут!

Try/except дешёвый, если не генерится исключение, а генериться оно должно редко, это ведь исключительная ситуация

Спасибо!

Спасибо! А что бы вы отметили, что за последнее время стало лучше на ваш взгяд? Темы видео, подача, картинка, звук, ещё что-то? Полезно будет знать. Спасибо!

наверно что бы можно было понять где падает open а где read. Но это как то нелепо описывать условную логику через эксепшены.

100%!

Я так же)

Оно тоже затуманивает логику как и if на каждом шагу. Если except на каждом шагу то это не лучше а даже медленнее А если не на каждом шагу проверка нужна то можно и без if'а, и без локальных except (только большой "всё-ловящий" try/except)

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

Скоро-скоро!

Я писал в 2013м статью по базовому гиту - goloburdin.blogspot.com/2013/11/git-bitbucket-20.html Видео тоже планирую, просто хочется сделать что-то глубже, чем просто commit/pull/push/merge/checkout

Как вас вообще на работу взяли)

Дааа, .get очень удобный метод, тоже часто использую! Спасибо!

спасибо:)

@Вячеслав Украинцев так и есть. Поэтому они не про вадидацию. Но тут сторонняя библиотека, ну и асерты, прямо по назначению, я что-то и не использовал никогда.

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

@@t0digital Спасибо за ответ! :)

Исключения не медленнее if/else. Исключение медленнее только если оно происходит, но оно должно происходить редко, что следует даже из названия, исключение создано для исключительных ситуаций. docs.python.org/3/faq/design.html#how-fast-are-exceptions

@@t0digital Да глянул исходники для try если ключ проверяют вызывают _PyObject_GetDictPtr , для OS ещё не придумали как сделать try быстрее.

​@@t0digital Ещё работает для Tuple

github.com/heykarimoff/solid.python

try: something = some_dict["key"] except KeyError: # do some stuff pass else: some_func(something) Напр, так

try/except плюс-минус такой же дешевый, как и if, если не возбуждается исключение. Когда оно возбуждается - это дороже, чем if. Но соль в том, что исключение оно на то и исключение, что должно возбуждаться редко.

@@t0digital Спасибо за ответ!

Всегда не надо, надо, когда есть вероятность, что ключа нет в словаре. Когда что-то может пойти не так в программе, на это надо заложиться

@@t0digital вот на фронтэнде так всегда приходится делать потому сервера часто падают и поэтому в большинстве случаев так приходится делать

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

Те кто отключают интернет во время деплоя))

Можно. Только получите эту неожиданную ошибку и надо неожиданно с ней разбираться. Тут искусственные примеры были и в реальности все сложнее. И проще. Нет одного такого EAFP на всем случаи жизни. if конечно лучше, но просто не всегда надо или придется этот if включать

Думаю, что имеется в виду кОтаны. Ну т.е. мальчики выросшие из котяток... 😃

Хахаах, спасибооо!

почему?

Исключение такие же дешёвые, как if, если не возникает исключения, а возникать они должны редко исходя даже из названия. Что if более читаем, чем except - нет же. В исключении явно понятно, какая логика нормальна, какая исключительна, в if else обе ветки равнозначны и без контекста, без коментов это непонятно. Райзить Exception вместо KeyError или IndexError - не надо.

@@t0digital 1. Style docs.python.org/3.8/faq/design.html#how-fast-are-exceptions 2. Performance paltman.com/try-except-performance-in-python-a-simple-test/ 3. - Как в коде, который покрыт несколькими слоями try except finally, излишние try, усложняет структуру кода, доп отступами от которых не избавиться. - Две строки, лучше чем четыре. - Как быть здесь? На каком ключе споткнулись? try: value = data['key1']['key2'] except IndexError: pass - может все же вот так понятней? if 'key1' not in data: raise Exception('исчерпывающий ответ что пошло не так') исполнение продолжилось. - к какому жесткачу, приводит неосторожное использование. try: value = function() except Exception: pass - трактовки. Что можно ожидать от if key in data ? Наверно, проверку вхождения, в массив, в строку или есть ли ключ в hashmap, зависит от типа данных data. Что можно ожидать от try except. Очень много всего, особенно когда обернута функция, и глубину вызовов внутри этой функции не видно, и на любом этапе может произойти исключение, которое этот перехват скроет. А бывает и приведет к некорректному исполненbю алгоритма. - нарушение логики. С исключениями, мы предпочитаем сначала наступить в кучу навоза, а потом принимать решение. А проще, посмотреть прежде чем наступать нет ли там кучу с помощью if. Что на итог: Эту конструкцию, опытный разработчик назовет вкусовщиной. Я же против этих конструкций, т.к. мы не все опытные и знаем все подводные камни и отдаем себе отчет в них, и суем их всюду. И это приводит к страшным поломкам. Чего не случится, если бы использовали if.

Так и не предлагается везде заменить if на try/except

1C сам по себе считается плохим тоном. P.S. Ладно, шутка

@@user-dv9fk1hd3s давай напишем систему лучше) Аналогов я не нашел, ниша свободна. Не шутка)

в чем дороговизна, поясните плз.

нет никакой дороговизны, по крайней мере в случае CPython. stackoverflow.com/questions/2522005/cost-of-exception-handlers-in-python docs.python.org/3/faq/design.html#how-fast-are-exceptions

@@user-ht3yt6yb9k абсолютно согласен с вами. На первое место в питоне надо ставить читабельность и простоту кода.

В случае со словарем проще воспользоваться методом get: dict_instance.get("key", "default value")

​@@TheNechXD С одной стороны да, но ведь работа с дефолтным значением концептуально отличается от работы с запрашиваемым значением. Поэтому, скорее всего, дальше все равно придется ветвить "программный поток" и обрабатывать дефолтное значение отдельно. Хотя, признаю, иногда полезно использовать дефолт, например, если дальше по программе оно уже обрабатывается

@@TheNechXD а если мне не нужно дефолтное значение? Смысл вопроса в действиях если ключа нет, а не в том, что мы получаем.

@@user-nj1bh7zs7d При вашем подходе вы также 2 раза проверяете наличие ключа в словаре. Читабельней ли это выглядит? Спорно. Неплохое решение предлагает Java с встроенными в Optional монадами. Ваш подход решает, например, проблему вложенных if'ов (если бы они были и вы сразу бы обрезали ветвь, классический пример), но концептуально не решает поставленную задачу лучше.

@@TheNechXD не понял почему 2 раза проверяю. С Java не знаком, но знаком с C#, там есть что-то подобное (Optional монады)?

try/except быстр, когда не генерится исключение, а генериться оно должно редко