«С — это причина, по которой придумали 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
🍾 — Если за такое не грех и бутылочку откупорить

​​pyleak | Контроль утечек памяти

Минималистичная библиотека для поиска утечек памяти умеет группировать утекшие объекты по типу, упрощая диагностику. Основной интерфейс — контекстный менеджер leak_checker(), который можно легко встроить в тесты или отладочные блоки. Отличный выбор для тех, кто хочет контролировать потребление памяти без тяжёлых инструментов.

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

Построчная безопасность (Row-Level Security) в SQL

RLS — одна из ключевых функций SQL, позволяющая реализовать контроль доступа на уровне отдельных строк таблицы. Вместо того чтобы писать сложные фильтры в каждом запросе, вы можете централизованно задать политику безопасности, которая будет автоматически применяться при чтении или изменении данных. Это упрощает архитектуру приложений и делает защиту данных более надежной.

Зачем это нужно

Обычно контроль доступа к данным реализуется в коде приложения. Например, чтобы пользователи видели только свои записи, вы добавляете фильтр WHERE user_id = @current_user. Но что, если по какой-то причине фильтр не применится? Чувствительные данные могут стать «достоянием общественности».

С помощью RLS вы перекладываете этот контроль внутрь базы данных. БД сама будет фильтровать строки в зависимости от настроек безопасности — даже если разработчик забудет что-то учесть в запросе.

Как работает RLS

Механизм реализуется через два ключевых механизма:

— Функция фильтрации определяет, какие строки доступны пользователю;
— Политика безопасности (Security Policy) привязывает эту функцию к конкретной таблице и операциям (SELECT, INSERT, UPDATE, DELETE).

Когда вы выполняете запрос к таблице с активной политикой RLS, SQL неявно вызывает фильтрующую функцию для каждой строки и исключает те, доступ к которым запрещён.

Пример

Шаг 1: Подготовка таблицы

CREATE TABLE Sales (
    Id INT,
    Amount MONEY,
    Region NVARCHAR(50)
);

Шаг 2: Создание функции фильтрации

CREATE FUNCTION fn_securitypredicate(@Region AS NVARCHAR(50))
RETURNS TABLE
WITH SCHEMABINDING
AS
RETURN SELECT 1 AS result WHERE @Region = SESSION_CONTEXT(N'region');

Эта функция возвращает строку только в том случае, если регион совпадает с регионом, записанным в сессии.

Шаг 3: Создание политики безопасности

CREATE SECURITY POLICY SalesFilter
ADD FILTER PREDICATE dbo.fn_securitypredicate(Region) ON dbo.Sales
WITH (STATE = ON);

Теперь каждый запрос к таблице Sales автоматически фильтруется.

Шаг 4: Установка параметра в сессии

EXEC sp_set_session_context 'region', 'West';
SELECT * FROM Sales; -- покажет только строки с Region = 'West'

Advanced RLS: Безопасность

Можно создать отдельную блокирующую политику (Block Predicate), чтобы запретить изменения недопустимых строк:

CREATE FUNCTION fn_blockpredicate(@Region AS NVARCHAR(50))
RETURNS TABLE
WITH SCHEMABINDING
AS
RETURN SELECT 1 AS result WHERE @Region = SESSION_CONTEXT(N'region');

CREATE SECURITY POLICY SalesBlocker
ADD BLOCK PREDICATE dbo.fn_blockpredicate(Region) ON dbo.Sales
AFTER INSERT, UPDATE
WITH (STATE = ON);

Теперь пользователь не сможет вставить или изменить строку, если не имеет на это права.

#основы

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

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

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

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