Python Какая принципиальная разница в записи условия?

Question

[Алексей Полоз]

Есть ли разница во времени исполнении таких конструкций?
И какая конструкция считается более читабельной?

if <громадное условие>:
   func(x,y,z)

И

func(x,y,z) if <громадное условие>

Answer 1

[Roman K]

Разница в том, что вторая конструкция требует else

Answer 2

[Bastax13]

Во-первых, первый вариант более читабельный. Лично я всегда использую именно "полный" вариант условия, если этот проект в будущем будет поддерживаться (другими людьми в т.ч.).
Во-вторых, как написал Roman Kitaev, "короткая" конструкция требует наличия else, а иногда этот else нам просто ни к чему.

Comments

[Алексей Полоз]

В данном случае?

[Bastax13]

Алексей Полоз: Нет, в данном случае уместно использовать именно сокращённую версию, т.к. у вас просто меняется значение переменной. В случае с какими-нибудь лямбда функциями я бы лучше написал в несколько строк.

[Anatoly Scherbakov]

Алексей Полоз: Было бы полезно предварительно сохранить элементы sys.argv как отдельные именованные переменные. Если какая-то не задана - то переменная будет иметь None. Тогда на длину массива аргументов проверять не надо. Код станет гораздо более читабельным.

Answer 3

[xdgadd]

Второй вариант называется тернарным оператором.

Если у вас крупное выражение, лучше использовать развернутую запись:

if big_expression and another_big_expressions or ... :
    do_stuff()
else:
    do_another_stuff()

А вот в случае простых выражений, стоит использовать тернарный оператор(во многом это зависит от кодстайла вашего проекта):

def foo(bar, buzz):
    ...
    return bar if expression else buzz

Answer 4

[Anatoly Scherbakov]

Позволю себе добавить к словам других комментаторов: обычно лучше не делать "громадные условия", их трудно читать. Почти всегда можно как-нибудь оптимизировать и сократить, например, разложив его на отдельные переменные, или составляя список и натравливая на него any() / all(), или вынося это всё в отдельную функцию с кучей assert, вместо условия ловя AssertionError.