shebang: что это и как запускать скрипты в CLI без слова python?

При работе с Unix-подобными системами (Linux, macOS), часто используется специальная строка, которая называется 'shebang' (шибэнг). Это первая строка в скрипте, которая начинается с символов #!, за которыми идёт путь к интерпретатору, который должен выполнить этот скрипт:

#!/usr/bin/env python3

print("Hello world")

Это равносильно: «Для запуска этого файла используй интерпретатор python3, который находится в вашем PATH».

Перед запуском сделаем файл исполняемым (или сразу всю директорию):

chmod +x myscript.py
chmod +x misc/*.py 

Теперь скрипт можно запустить так:

./myscript.py

Как правильно писать shebang для Python?

Существует несколько распространённых вариантов записи shebang для Python:

1. Абсолютный путь

#!/usr/bin/python3

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

2. Использование `/usr/bin/env`:

#!/usr/bin/env python3

Команда env ищет в текущем окружении пользователя нужный интерпретатор по имени python3 и запускает его. Это значит, что не важно, где установлен Python, скрипт всё равно будет работать, если python3 доступен в PATH.


Что произойдет без shebang?

Если запустить скрипт без shebang напрямую (./myscript.py), система не поймет, каким интерпретатором его запускать, и выдаст ошибку.

p.s. На Windows shebang не используется системой напрямую, но некоторые инструменты (например, Git Bash, WSL, или IDE) могут её «наследовать».

#основы
@zen_of_python

​​Vitess | Шардирование для вашей PostgreSQL

Это слой между приложением и базой данных, созданный выходцами из YouTube для защиты от неэффективных запросов и масштабируемости под экстремальными нагрузками. Он также анализирует SQL-запросы на лету, отсекая потенциально опасные. Vitess — система шардирования, основа для Multigrass — проекта по адаптации для PostgreSQL внутри Supabase. Vitess стал частью их инфраструктуры, чтобы приложения могли расти до миллиардов запросов, оставаясь при этом "просто PostgreSQL".

Сайт проекта
#инструмент
@zen_of_python

logging | Эволюционируем от дебага с print()

Вместо хаотичного использования print() стоит освоить встроенный модуль logging.

Почему print() — не лучший выбор

На начальном этапе разработки многие прибегают к такому для отладки. Однако в продакшене такой подход не подходит:

— print() не имеет уровней важности (debug, info, error…);
— нельзя гибко управлять выводом (в файл, консоль, внешнюю систему)
— невозможно централизованно отключить или настроить поведение.

logging решает все эти задачи и стал стандартом в профессиональной разработке.

База

Минимальный пример:

import logging

logging.basicConfig(level=logging.INFO)
logging.info("Программа запущена")

Этот код выведет в консоль строку «информирующего» уровня. Метод basicConfig задает базовые настройки — например, какой минимальный уровень логов выводить. Уровней несколько:

— DEBUG: подробная отладочная информация;
— INFO: стандартный рабочий поток;
— WARNING: потенциальные проблемы;
— ERROR: ошибки, но программа продолжает работать;
— CRITICAL: фатальные ошибки, возможно аварийное завершение.

Они позволяют фильтровать отладочные данные в зависимости от задачи.

Форматирование вывода

Полезно выводить время, уровень и контекст:

logging.basicConfig(
    level=logging.INFO,
    format="%(asctime)s [%(levelname)s] %(message)s"
)

Выведется нечто подобное:

2025-07-07 14:00:00,123 [INFO] Программа запущена

Запись логов в файл

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

logging.basicConfig(
    level=logging.INFO,
    filename='app.log',
    filemode='a',
    format="%(asctime)s [%(levelname)s] %(message)s"
)

Обособленные логгеры

Функция getLogger(name) позволяет создавать независимые логгеры с именем:

logger = logging.getLogger("myapp")
logger.setLevel(logging.DEBUG)
logger.debug("Отладочная информация")

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

Обработчики (Handlers)

В примере ниже все сообщения уровня DEBUG и выше пишутся в файл, а WARNING+ отображаются в консоли:

handler = logging.FileHandler("debug.log")
handler.setLevel(logging.DEBUG)

console = logging.StreamHandler()
console.setLevel(logging.WARNING)

formatter = logging.Formatter("%(asctime)s [%(levelname)s] %(message)s")
handler.setFormatter(formatter)
console.setFormatter(formatter)

logger = logging.getLogger("myapp")
logger.addHandler(handler)
logger.addHandler(console)
logger.setLevel(logging.DEBUG)

И напоследок: пишите логи в файл или систему мониторинга вроде Sentry или Grafana.
#основы

​​lxml обновился

Небезызвестный тул для парсинга XML / HTML в Python-коде получил мажорное обновление, и в нем:
— обновили зависимости;
— отказались от Python 2;
— повысили стабильность и безопасность;

Release Note
#инструмент
@zen_of_python

dripdrop | Стриминг JSON

Экспериментальный инструмент, который позволяет стримить данные в ваших API. Он возвращает клиенту JSON-скелет с плейсхолдерами вместо данных и постепенно заполняет его по мере готовности асинхронных результатов. DripDrop реализует концепцию прогрессивного JSON, вдохновленную React Server Components, чтобы ваши интерфейсы могли отображать данные без ожидания самых медленных запросов (Skeleton Loader). Быстрые части ответа отправляются сразу, а медленные догружаются потоками через JSON Lines.

Репозиторий проекта
#инструмент
@zen_of_python
💘 — Если нравится Skeleton Loader

​​curlify | Из requests в cURL

Инструмент для преобразования запросов из requests в эквивалентные «курлы». Он автоматически добавляет все необходимые флаги, включая -X, -H, -d, --compressed и другие, чтобы команда точно отражала параметры исходного запроса. Благодаря опции pretty=True можно получить красиво отформатированную, многострочную cURL-команду, удобную для чтения и вставки в консоль. Библиотека заботится о безопасности и корректности, надежно экранируя кавычки и специальные символы для совместимости с командной строкой.

Репозиторий проекта
#инструмент
@zen_of_python

throttled-py | Ограничение частоты запросов

Если вам нужно защищиться от DDoS-атак, контролировать затраты и в целом оптимизировать производительность, эта библиотека поддерживает популярные алгоритмы: Fixed / Sliding Window, Token Bucket и проч. Она подходит для как синхронных, так и асинхронных приложений. Для хранения состояния лимитов можно использовать как быстрый In-Memory режим, так и масштабируемый Redis-бэкенд. «Питонический дроссель» интегрируется с MCP Python SDK, позволяя эффективно контролировать частоту вызовов в диалоговых процессах моделей.

Репозиторий проекта
#инструмент
@zen_of_python

Вопросы подписчиков

Zen of Python поддерживает новоприбывших (и не только) в особой рубрике. Как это работает:

— Спрашивайте что угодно (в комментариях под этим постом), связанное с Python. Здесь нет плохих вопросов!
— Сообщество вас поддержит. Самые интересные вопросы мы разберём в отдельном посте;

#вопросы_новичков
@zen_of_python

Честный ресёрч найма в IT прямо с рынка

Вместе с Proglib мы разобрали, почему айтишники реально уходят с работы, по каким признакам вычислить токсичный коллектив и какие HR-трюки бесят разработчиков больше всего. Если ещё не читали — советуем это исправить❤️

Бонусом мы подготовили ещё два полезных лонгрида из этого исследования:
— Где искать работу в IT: лайфхаки и топ-площадки
— Каких разработчиков переизбыток и кому сейчас сложнее найти вакансию

Сохраняйте и кидайте коллегам!

«С — это причина, по которой придумали Python»
#кек
@zen_of_python

Old but gold

@ithumor

Почему вам стоит попробовать uv

До недавнего времени написание «однострочных» Python‑утилит оборачивалось головной болью: нужно настраивать виртуальное окружение, докачивать зависимости, проверять соответствие версии Python… uv решила это, предложив Rust‑реализацию лёгкого, быстрого менеджера пакетов, способного:

— автоматически создавать «утилизируемые окружения»;
— скачивать нужные зависимости;
— исполнять вышеописанное и запускать сам скрипт в одну команду.

uv действительно быстр и «бросает настройку окружения в мусорную корзину» .


PEP 723: метаданные прямо в скрипте

PEP 723 — это спецификация, позволяющая внедрить информацию о зависимостях внутри самого файла скрипта. В начале файла прописывается пример:

# /// script
# requires‑python = ">=3.11"
# dependencies = [
#   "requests<3",
#   "rich",
# ]
# ///

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


Комбо: uv + PEP 723

Есть файл pep.py с вышеописанным PEP‑блоком — и вот что происходит:

$ uv run pep.py
Installed 9 packages in 24ms
[('1', 'PEP Purpose…'), … ]

uv прочитывает метаданные, ставит окружение, запускает скрипт — и всё это без лишних слов.


Пример: скрипт для выкачки транскрипта YouTube

Взгляните на пример скрипта для выкачки субтитров с YouTube-видео:

#!/usr/bin/env -S uv run --script
# /// script
# requires‑python = ">=3.8"
# dependencies = ["youtube-transcript-api"]
# ///
import sys, re
…
transcript = YouTubeTranscriptApi().fetch(video_id)
print(formatter.format_transcript(transcript))

После chmod +x ytt он запускается так:

$ ./ytt https://youtu.be/[video_id]
Installed 7 packages in 10ms
…текст транскрипта…

#основы

Ngrok: безопасный туннель к локальному серверу за пару секунд

Когда нужно показать локальный проект клиенту или протестировать вебхук от стороннего сервиса, поднимать полноценный сервер в интернете — избыточно. Ngrok решает эту задачу: за секунды пробрасывает туннель из интернета к вашему локальному серверу, выдавая публичный URL. Поддерживает HTTPS, защищённые токены, инспекцию трафика и работает на всех популярных ОС.

Так, вы можете безо всякого труда прямо в VS Code расшарить свой localhost, чтобы похвастаться другу или обсудить детали с клиентом.

#бэкенд #инструменты

​​pytest-benchmark | Если тесты, то грамотно

Питонический плагин, позволяющий замерять производительность под всевозможными углами. Запускает тесты многократно, сглаживая статистический шум и выявляя реальные изменения скорости выполнения. Плагин выводит в отчете системные параметры (CPU, версия ЯП и др.), чтобы бенчмарки были воспроизводимыми и сопоставимыми. Поддерживается сравнение результатов между запусками, что удобно для отслеживания деградации. Инструмент встраивается в CI/CD-пайплайны.

Цена: бесплатно
Репозиторий проекта
@prog_tools

создатели TikTok выкатили БЕСПЛАТНЫЙ аналог Cursor, еще и OPEN-SOURCE

ByteDance (да-да, те самые) выложили на GitHub исходники Trae Agent — ИИ-ассистента для программистов, который умеет писать код, править баги, задавать сам себе вопросы и даже запускать команды в терминале.

То есть буквально как Cursor, но с открытым кодом и без подписки на $60.

Что умеет:

- редактирует файлы и пишет коммиты,
- сам решает, что делать: рефакторить, тестить или гуглить,
- работает с GPT-4, Claude, OpenRouter и даже Doubao (внезапно),
- сохраняет «траекторию» своих действий — можно проверить, что он натворил.

Ссылка на GitHub: тык

@your_tech

__init__.py в Python: зачем он нужен и как с ним работать

Файл __init__.py играет ключевую роль в функционировании модулей и пакетов. В этой посте разберём, зачем нужен этот файл, как его использовать, и какие трюки можно с ним провернуть.

__init__.py используется для обозначения директории как пакета Python. Пакет — это просто каталог, содержащий код, который можно импортировать. До Python 3.3 файл __init__.py был обязателен для того, чтобы Python распознавал директорию как пакет. Начиная с Python 3.3, это уже не строго обязательно благодаря PEP 420, который ввёл поддержку 'implicit namespace packages'.

Тем не менее, __init__.py всё ещё активно используется, потому что он позволяет:

— Настроить импорты, переменные окружения и т.д.;
— Реализовать алиасы и проксировать импорты;
— Управлять логикой и поведением при импорте.

Пример: простой пакет с __init__.py

my_package/
├── __init__.py
├── module1.py
└── module2.py

В __init__.py можно явно указать, какие модули экспортируются:

from .module1 import func1
from .module2 import func2

__all__ = ['func1', 'func2']

Теперь из внешнего кода можно написать:

from my_package import func1, func2

И это сработает — благодаря тому, что __init__.py делает интерфейс «плоским».

Что можно писать в __init__.py

Всё, что угодно — это обычный Python-скрипт. Вот что часто в нём делают:

1. Инициализация логики:

import logging

logging.getLogger(__name__).addHandler(logging.NullHandler())

2. Упрощение структуры:

# Вместо длинного:
from my_package.module1.submodule import ClassA

# можно:
from my_package import ClassA

И в __init__.py:

from .module1.submodule import ClassA

3. Версионирование:

__version__ = "1.0.0"

4. Работа с абсолютными и относительными импортами:

Python различает абсолютные и относительные импорты. Благодаря __init__.py, относительные импорты типа from . import module1 работают корректно.

Когда __init__.py не нужен

PEP 420 ввёл концепцию namespace packages — это директории без __init__.py, которые Python всё равно распознаёт как пакеты. Это удобно, когда вы хотите:

— Распределить один пакет между несколькими каталогами (например, для плагинной архитектуры);
— Избежать необходимости в поддержке пустых __init__.py.

Пример:

project/
├── pkg/
│   └── subpkg1/
│       └── a.py
└── other/
    └── pkg/
        └── subpkg2/
            └── b.py

Если в pkg/ нет __init__.py, Python объединит содержимое в один namespace package.

Когда __init__.py обязателен

— При тестировании и использовании pytest (некоторые тест-раннеры не обнаруживают модули без `__init__.py`);
— При работе с устаревшими инструментами;
— При построении плоского интерфейса пакета;
— Для поддержки специфичных путей и логики импорта.

#основы

Django 20 лет!

Если вы сегодня выпьете, ваша женщина не имеет право осудить вас: такие юбилеи бывают нечасто. Соавтор фреймворка Саймон Виллисон поделился историей проекта в своем блоге. Он также признался, что совсем не умеет доводить идеи до ума. Их накопилось так много, что даже пришлось выуживать из Internet Archive.

Теперь можно проводить тест на возраст «А ты помнишь первую версию фреймворка?"

#факт
@zen_of_python
🍾 — Если за такое не грех и бутылочку откупорить