Почему в Python проще попросить прощения, чем получить разрешение?

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

Причина, по которой Python является EAFP, заключается в том, что, в отличие от других языков (например, Java), в Python перехват исключений является относительно недорогой операцией, и поэтому вам рекомендуется ее использовать.

Пример для EAFP:

try:
    snake = zoo['snake']
except KeyError as e:
    print "There's no snake in the zoo"
    snake = None

Пример для LBYL:

if 'snake' in zoo:
    snake = zoo['snake']
else:
    snake = None

Здесь вы смешиваете две вещи: утверждения и логику на основе EAFP.

Утверждения используются для проверки контракта функций, то есть его пред- и постусловий, а иногда и его инвариантов. Они гарантируют, что функция будет использоваться так, как она должна использоваться. Однако они не предназначены для потока кода, поскольку полностью прерывают выполнение при ошибке. Типичным примером является проверка None аргументов в вызовах функций.

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

Теперь EAFP — это нечто другое. Он используется в потоке управления, или, скорее, он позволяет избежать дополнительного потока управления в пользу того, чтобы ожидать, что все будет правильно, и вместо этого перехватывать исключения, если они неверны. Типичным примером, показывающим разницу, является доступ к ключу в словаре:

# LBYL
if key in dic:
    print(dic[key])
else:
    handleError()

# EAFP
try:
    print(dic[key])
except KeyError:
    handleError()

Теперь это выглядит очень похоже, хотя вы должны иметь в виду, что решение LBYL проверяет словарь дважды. Как и в случае со всем кодом, перехватывающим исключения, вы должны делать это только в том случае, если отсутствие ключа является исключительным случаем. Поэтому, если обычно предоставленный ключ не содержится в словаре, то это EAFP, и вы должны просто получить к нему прямой доступ. Если вы не ожидаете, что ключ будет присутствовать в словаре, то вам, вероятно, следует сначала проверить его существование (хотя исключения в Python дешевле, они все же не бесплатны, поэтому оставьте их для исключительных случаев).

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

Хороший вопрос! В StackOverflow очень мало вопросов о «философии, лежащей в основе принципа».

Что касается определения EAFP в глоссарии Python, я бы даже пошел дальше. и говорят, что его упоминание об «исключениях кэширования, если предположение оказывается ложным» в этом контексте несколько вводит в заблуждение. Потому что, скажем прямо, следующий 2-й фрагмент кода НЕ выглядит более «чистым и быстрым» (термин, используемый в вышеупомянутом определении). Неудивительно, что ОП задал этот вопрос.

# LBYL
if key in dic:
    print(dic[key])
else:
    handleError()

# EAFP
try:
    print(dic[key])
except KeyError:
    handleError()

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

# Real EAFP
print(dic[key])

Теперь, разве это не настоящий подход EAFP, чистый и быстрый?

Я расширим ответ от @RayLuo.

Проблема с LBYL в том, что он вообще не работает. Если у вас нет однопоточного приложения, всегда возможно состояние гонки:

# LBYL
if key in dic:
    # RACE CONDITION
    print(dic[key])
else:
    handleError()

# EAFP
try:
    print(dic[key])
except KeyError:
    handleError()

Ключ можно добавить в словарь между проверкой if и print. В данном конкретном случае это не кажется невероятно вероятным. Однако гораздо более вероятно, что проверка, которую вы выполняете, связана с базой данных, API или любым внешним источником данных, который может изменяться асинхронно с данными вашего приложения.

Это означает, что правильный способ реализации LBYL:

if key in dic:
    try:
        print(dic[key])
    except KeyError:
        handleError()
else:
    handleError()

Обратите внимание, что предложение try / except точно такое же, как и в подходе EAFP.

Поскольку вы должны обрабатывать исключение в стиле EAFP даже при использовании подхода LBYL, вы могли бы также использовать подход EAFP в первую очередь.

Единственное обстоятельство, при котором я бы использовал проверку if, — это если последующее действие (в данном случае print) очень дорогое / требует много времени для инициирования. Это было бы редкостью и не было бы причиной каждый раз использовать проверку if.

Итог: LBYL в общем случае не работает, но EAFP работает. Хорошие разработчики сосредотачиваются на общих шаблонах решений, которые они могут уверенно использовать в широком диапазоне задач. Научитесь использовать EAFP последовательно.