или статическая, поди разбери

поделитесь пожалуйста этими нижками, у кого есть?

динамическая, строгая.

Апи это среднее между беггигерс и профи?

это в питоне, а чё пацаны пишут - хз

ой ну ок ) обосрали.  Короче имел в виду в тайп хинты яростно оборачивают для статического анализатора , свой DI запилили, декораторы злые и тп. Есть прикольные вещи типа стартер кита для джанги или питона, есть сомнительные, как по мне:  DI или DSL, например.

мне кажется подход EAFP (try... except) более простым, наглядным и питонячьим, чем LBYL (if'ы).

EAFP - Easier to ask for forgiveness than permission. This common Python coding style assumes the existence of valid keys or attributes and catches exceptions if the assumption proves false. This clean and fast style is characterized by the presence of many try and except statements. The technique contrasts with the LBYL style common to many other languages such as C.

LBYL - Look before you leap. This coding style explicitly tests for pre-conditions before making calls or lookups. This style contrasts with the EAFP approach and is characterized by the presence of many if statements.

In a multi-threaded environment, the LBYL approach can risk introducing a race condition between “the looking” and “the leaping”. For example, the code, if key in mapping: return mapping[key] can fail if another thread removes key from mapping after the test, but before the lookup. This issue can be solved with locks or by using the EAFP approach.

мнение автора статьи, впрочем, тоже понятно и я с ним тоже согласен по-своему

утверждение "Исключения в Python теперь считаются анти-паттерном", вынесенное в заголовок статьи - это примерно как сказать "автомобили с ДВС - антипаттерн, с этого дня - только электромобили", то есть в этом есть некий смысл, возможно, некая хорошая цель, но это совершенно не та картина мира, которую мы наблюдаем сегодня, современный мир не готов прямо сейчас это принять... на пути к этой цели должны быть приняты соотвествубщие PEP'ы, из документации питона и популярных либ должны быть убраны соответствующие примеры использования и вставлены другие и вот тогда, возможно, через несколько лет описанный в статье подход станет основным...

не-не, там со статьей все понятно, парень фанатик, не видит, что получается очень громоздко, я про вообще

по данному вопросу я считаю своё мнение необъективным, мне нравится "как проще" и мне нравится EAFP, в критичных местах (эй, а почему это на питоне?) я согласен с тем, что явные проверки через if'ы лучше

мне наоборот кострукции try except кажутся громоздкими и неудобными

думаю, тут от восприятия ещё многое зависит: вот, к примеру, есть некий get-метод, который по id вытаскивает объект, он пробует найти там объект, а его там нет... как воспринимать это? делать исключение - это воспринимать как "шеф, всё пропало! бросаем всё и бежим отсюда скорее, миссия провалена", если это воспринимается как некая критическая ошибка - исключения кажутся уместными

и, полагаю, это противоречит тому подходу, который пропагандируется в, например, Go...

ну вот здесь мне кажется наоборот городить except это что-то вроде "мы попробуем, а дальше как оно там хз"

а обрабатывая это исключение ты сразу говоришь - такое бывает, так что вот вам сценарий.

с примером про get
там есть два кейса

объекта не найдено
и найдено больше одного

по логике get подразумевает получение и получение одного объекта

в даном кейсе

с помощью исключений есть возможность реагировать на каждый кейс по своему

те фреймворк посылает вам сигнал
что есть ситуация не укладывающаяся в сценарий
и надо реагировать

тут в чём основная проблема с исключениями - это всё происходит неявно, программист запрашивает get() и не уверен в том, какие исключения ему там прилетят в ответ, если прилетят