Телеграм канал «Постоянный репозиторий по Python»

🐍 Почему pass — это не "ничего не делает"

Когда изучают Python, часто говорят:
pass — это оператор, который ничего не делает.
Формально это правда.
Но тогда возникает вопрос:

Зачем он вообще нужен?
Представьте, что вы только начинаете писать класс:
class User:
    pass
Или функцию:
def process_data():
    pass
Или пока не реализовали одну из веток условия:
if debug:
    pass
else:
    print("Программа работает")
Без pass такой код вообще не запустится.

Почему?
В Python после двоеточия обязательно должен находиться блок кода.

Например:
if x > 10:
Так написать нельзя.
Интерпретатор сразу сообщит об ошибке, потому что ожидает тело конструкции.

Именно здесь помогает pass.
Он говорит интерпретатору:
«Да, этот блок существует. Просто пока он пустой.»

Когда pass действительно полезен?
✅ Создание каркаса программы.
Когда сначала проектируют архитектуру, а реализацию добавляют позже.
✅ Абстрактные классы.
Иногда методы объявляют заранее, чтобы реализовать их позднее.
✅ Временная заглушка.

Во время разработки можно написать:
def export_pdf():
    pass
И спокойно продолжать писать остальную программу.

А можно просто написать комментарий?
Нет.
Такой код:
if is_admin:
    # TODO: добавить проверку
 
не запустится.

Комментарий не считается инструкцией.
pass — считается.

Интересный факт
У pass есть «родственники», которые тоже часто путают между собой:
pass — ничего не делает;
continue — переходит к следующей итерации цикла;
break — полностью завершает цикл.
Они выглядят похоже, но решают совершенно разные задачи.

💡 Вывод
pass — это не бесполезная инструкция.
Это способ сказать Python:
«Этот блок кода появится позже, а пока оставь его пустым.»
Именно поэтому pass очень часто встречается в реальных проектах, а не только в учебных примерах.

💬 А вы используете pass?
👍 Да, часто при разработке.
🤔 Иногда, как временную заглушку.
😅 Думал, что он нужен только в учебниках.

🐍 sorted()не изменяет список. И это спасает от многих ошибок.

Представьте ситуацию.
Есть список:
 
numbers = [5, 1, 8, 3, 2]
 
Вы хотите вывести его в отсортированном виде и пишете:
 
print(sorted(numbers))
 
Получаете: [1, 2, 3, 5, 8]
 
А теперь проверим исходный список:
 
print(numbers)
 
Результат: [5, 1, 8, 3, 2]
 
Он не изменился.

Многие думают, что это ошибка
Но именно так и задумано.
Функция sorted() создаёт новый отсортированный список, не изменяя исходные данные.
Это очень удобно, когда:
данные нужны ещё и в первоначальном порядке;
один и тот же список используется в разных частях программы;
нужно избежать случайного изменения данных.

А вот sort() работает иначе
 
numbers.sort()
 
После этого:

print(numbers)
 
получим: [1, 2, 3, 5, 8]
 
Теперь список изменился навсегда.

Что выбрать?
Используйте sorted(), если:
✅ нужно сохранить исходные данные;
✅ хотите получить новую отсортированную коллекцию;
✅ работаете в функциональном стиле.
Используйте sort(), если:
✅ список больше нигде не нужен в исходном виде;
✅ важна экономия памяти;
✅ сортировка выполняется «на месте».

Интересный факт
sorted() работает не только со списками.
Она умеет сортировать практически любые итерируемые объекты:
 
sorted("python")
 
['h', 'n', 'o', 'p', 't', 'y']
 
или даже:
 
sorted({5, 2, 9, 1})
 
[1, 2, 5, 9]
 
о есть результатом sorted() всегда будет список, независимо от типа исходной коллекции.

💡 Запомнить просто
sorted() — создаёт новый список.
sort() — изменяет существующий.

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

🐍 Миф: если код короче — значит он лучше
У Python есть репутация языка, на котором можно писать очень компактный код.
Но иногда желание написать всё в одну строку приводит к обратному эффекту.

Например:
 
result = [x**2 for x in numbers if x % 2 == 0 and x > 10 and x < 100]
 
Такой код вполне корректен.
Но попробуйте понять его через полгода.
А теперь сравните с этим вариантом:
 
result = []
 
for number in numbers:
    if number % 2 != 0:
        continue
 
    if number <= 10 or number >= 100:
        continue
 
    result.append(number ** 2)
 
Да, строк больше. Но логика читается буквально сверху вниз.

Почему опытные разработчики не гонятся за минимальным количеством строк?

Потому что код гораздо чаще читают, чем пишут.
Причём читает его не только коллега.
Через несколько месяцев этим «коллегой» можете оказаться вы сами.

Что говорит философия Python?
В модуле this есть одна очень известная строка:
Beautiful is better than ugly.
 
И ещё одна, которая подходит к этой теме ещё лучше:
 
Readability counts.
 
«Читаемость имеет значение.»

Именно эта идея лежит в основе Python.

Когда короткий код — это хорошо?
✅ Простая операция.
✅ Очевидная логика.
✅ Конструкция легко читается.

Когда лучше написать подробнее?
Если приходится:
перечитывать выражение несколько раз;
добавлять комментарии, чтобы объяснить одну строку;
использовать слишком много вложенных условий.
В этих случаях лучше разбить решение на несколько шагов.

💡 Хороший ориентир
Задайте себе простой вопрос:
Сможет ли другой разработчик понять этот код за 10–15 секунд?
Если ответ «нет», возможно, стоит пожертвовать несколькими строками ради понятности.

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