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

Почему list comprehension – это не просто «короче», а принципиально другой стиль мышления

Очень часто можно увидеть такой код:

result = []

for x in data:
if x > 0:
result.append(x * 2)

Работает. Всё понятно. Но это «императивный» стиль – шаг за шагом.

Как это выглядит в Python-стиле

result = [x * 2 for x in data if x > 0]

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

В чём реальная разница?

Это не просто «короче»:
• код становится декларативным
• легче читать «слева направо»
• проще комбинировать операции
• меньше промежуточных состояний

Почему это важно в аналитике и data-инженерии

Когда работаешь с данными, часто есть цепочка:
• фильтрация
• преобразование
• агрегирование

И list comprehension позволяет описывать это компактно:

[x["price"] for x in orders if x["status"] == "paid"]

Но есть ловушка ⚠️
Когда логика становится сложной — код превращается в кашу:

[x * 2 if x > 0 else x - 2 for x in data if x % 2 == 0]

👉 Это уже трудно читать

Когда использовать
✔️ простые фильтры
✔️ простые преобразования
✔️ короткие цепочки логики

Когда НЕ стоит
❌ сложные условия
❌ вложенные конструкции
❌ длинные выражения

В таких случаях обычный for читается лучше.

Главное правило
list comprehension – это не «сокращение кода», это способ мыслить через преобразование коллекций.

Вывод
Хороший Python-код – это не самый короткий код, а самый понятный при первом чтении.

Почему print()– плохой инструмент для отладки (и что использовать вместо)

Очень привычный подход:
print("x =", x)
print("result =", result)

Быстро, удобно… но у этого есть проблемы.

В чём проблема print()?

❌ Засоряет код
После отладки такие строки часто остаются
❌ Нет контроля
Нельзя легко отключить вывод
❌ Нет уровней важности
Ошибка и обычное сообщение выглядят одинаково
❌ Плохо масштабируется
В большом проекте превращается в хаос

Как делают правильно

Используют модуль logging:

import logging

logging.basicConfig(level=logging.INFO)

logging.debug("Это отладка")
logging.info("Обычная информация")
logging.warning("Предупреждение")
logging.error("Ошибка")

Почему это лучше?

✅ Гибкость
Можно включать/выключать уровни логов
✅ Контроль

Логи можно писать:
• в файл
• в консоль
• во внешние системы

✅ Структура
Есть уровни:
• DEBUG
• INFO
• WARNING
• ERROR

Ключевой момент

logging.debug("msg")

НЕ выполнится, если уровень выше.
👉 Это экономит ресурсы и делает код чище.

Где это особенно важно
• backend-сервисы
• data pipelines
• ETL-процессы
• долгие вычисления
• системы с пользователями

Когда print() всё-таки норм

✔️ быстрые проверки
✔️ обучение
✔️ одноразовые скрипты

Краткое правило
• маленький скрипт → можно print()
• проект / сервис → только logging

Вывод
print() – это инструмент новичка.
logging – инструмент разработчика.

Почему None нужно проверять через is, а не через ==

Очень частый код:

if value == None:
print("Нет значения")

Работает… но это неправильный подход.

Правильнее так 👇
if value is None:
print("Нет значения")

В чём разница?
• == сравнивает значения
• is проверяет идентичность объекта
А None в Python – это единственный объект (singleton).
То есть он существует в одном экземпляре.

Почему это важно?
Иногда == может вести себя неожиданно:
class Test:
def __eq__(self, other):
return True

obj = Test()

print(obj == None) # True
print(obj is None) # False

👉 Вывод: == None можно «сломать»

👉 is None – всегда работает корректно

Где это критично
• обработка отсутствующих данных
• функции с аргументами по умолчанию
• проверки перед вычислениями
• работа с API и базами данных

Частая ошибка ❌
if value == None:
if value != None:

Правильный стиль ✔️
if value is None:
if value is not None:

Краткое правило
• None → всегда через is
• всё остальное → через ==

Вывод
None – это не просто значение, это конкретный объект в Python.
И проверять его нужно соответствующим образом.