Использование try vs if в Python

Есть ли смысл решить, какую из конструкций tryили ifиспользовать при тестировании переменной на наличие значения?

Например, есть функция, которая либо возвращает список, либо не возвращает значение. Я хочу проверить результат перед его обработкой. Что из перечисленного было бы предпочтительнее и почему?

result = function();
if (result):
    for r in result:
        #process items

или

result = function();
try:
    for r in result:
        #process items
except TypeError:
    pass;

Связанное обсуждение:

Проверка существования члена в Python

Вы часто слышите, что Python поощряет стиль EAFP («проще попросить прощения, чем разрешения»), а не стиль LBYL («посмотрите, прежде чем прыгнуть»). Для меня это вопрос эффективности и удобочитаемости.

В вашем примере (скажем, что вместо возврата списка или пустой строки функция должна была вернуть список или None), если вы ожидаете, что 99% времени на resultсамом деле будет содержать что-то итеративное, я бы использовал этот try/exceptподход. Будет быстрее, если исключения действительно будут исключительными. Если resultэто Noneболее 50% случаев, то, ifвероятно, лучше использовать.

Чтобы подтвердить это с помощью нескольких измерений:

>>> import timeit
>>> timeit.timeit(setup="a=1;b=1", stmt="a/b") # no error checking
0.06379691968322732
>>> timeit.timeit(setup="a=1;b=1", stmt="try:\n a/b\nexcept ZeroDivisionError:\n pass")
0.0829463709378615
>>> timeit.timeit(setup="a=1;b=0", stmt="try:\n a/b\nexcept ZeroDivisionError:\n pass")
0.5070195056614466
>>> timeit.timeit(setup="a=1;b=1", stmt="if b!=0:\n a/b")
0.11940114974277094
>>> timeit.timeit(setup="a=1;b=0", stmt="if b!=0:\n a/b")
0.051202772912802175

Итак, в то время как ifутверждение всегда стоит вам денег, установить try/exceptблок почти бесплатно . Но когда это Exceptionпроисходит на самом деле, цена намного выше.

Мораль:

• Совершенно нормально (и "питонически") использовать try/exceptдля управления потоком,
• но это имеет смысл больше всего, когда Exceptions на самом деле исключительны.

Из документов Python:

EAFP

Проще просить прощения, чем разрешения. Этот общий стиль кодирования Python предполагает наличие действительных ключей или атрибутов и перехватывает исключения, если предположение оказывается ложным. Для этого чистого и быстрого стиля характерно наличие множества tryи exceptвысказываний. Эта техника контрастирует со стилем LBYL, общим для многих других языков, таких как C.

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

for r in function():
    # process items

Не обращайте внимания на мое решение, если предоставленный мной код на первый взгляд неочевиден и вам необходимо прочитать объяснение после примера кода.

Могу ли я предположить, что «значение не возвращено» означает, что возвращаемое значение - None? Если да, или если «нет значения» имеет логическое значение False, вы можете сделать следующее, поскольку ваш код по существу обрабатывает «нет значения» как «не повторять»:

for r in function() or ():
    # process items

Если function()возвращает что-то, что не соответствует истине, вы перебираете пустой кортеж, то есть не выполняете никаких итераций. По сути, это LBYL.

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

Что из перечисленного было бы предпочтительнее и почему?

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

(Я согласен с Брэндоном Корфманом: возврат None вместо «нет элементов» вместо пустого списка нарушен. Это неприятная привычка программистов Java, которая не должна встречаться в Python или Java.)

В общем, у меня сложилось впечатление, что исключения следует делать на исключительные обстоятельства. Если resultожидается, что он никогда не будет пустым (но может быть, если, например, произошел сбой диска и т. Д.), Второй подход имеет смысл. Если, с другой стороны, пустое значение resultвполне разумно при нормальных условиях, проверка его с помощью ifоператора имеет больше смысла.

Я имел в виду (более распространенный) сценарий:

# keep access counts for different files
file_counts={}
...
# got a filename somehow
if filename not in file_counts:
    file_counts[filename]=0
file_counts[filename]+=1

вместо эквивалента:

...
try:
    file_counts[filename]+=1
except KeyError:
    file_counts[filename]=1

bobince мудро указывает, что упаковка второго случая также может перехватывать TypeErrors в цикле, что вам не нужно. Если вы действительно хотите попробовать, вы можете проверить, повторяется ли он перед циклом.

result = function();
try:
    it = iter(result)
except TypeError:
    pass
else:
    for r in it:
        #process items

Как видите, довольно некрасиво. Я не предлагаю этого, но для полноты картины следует упомянуть об этом.

Что касается производительности, использование блока try для кода, который обычно не вызывает исключений, быстрее, чем использование оператора if каждый раз. Итак, решение зависит от вероятности исключительных случаев.

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