Что за зверь такой — Последовательная типизация?

Всем нам в первые пару лет, как правило, доносят про:

Динамическую типизацию — способ работы с типами данных, при котором тип переменной определяется во время выполнения программы, а не заранее (как при статической типизации).

Природа любит заполнять «дыры» между такими антонимами, поэтому Python умеет и в т.н. Последовательную типизацию — систему типов, в которой некоторым переменным могут быть заранее заданы строгие типы:

def greet(name: str, greeting) -> str:
    return greeting + ", " + name

name: str = "Alice"
print(greet(name, "Hello"))

Этот ненавязчивый гибрид сочетает достоинства динамической и статической типизаций:
— Улучшает качества кода — аннотации типов позволяют инструментам вроде mypy находить ошибки до запуска программы;
— Облегчает сопровождения больших проектов — типы помогают лучше понять интерфейсы функций и классов;
— Помогает с плавным переходом: можно добавлять типы поэтапно, не переписывая весь код сразу.

#основы
@zen_of_python

Из гайда по безопасности Django

Фреймворк известен своей философией «батарейки в комплекте». Однако даже с его встроенными средствами защиты, безопасность приложения во многом зависит от разработчика.

Современные веб-приложения сталкиваются с множеством угроз. Хотя Django предоставляет встроенные механизмы защиты от многих из них, полезно ознакомиться с основными InfoSec-практиками.

Обновление Django и зависимостей

Регулярно «освежайте» версию фреймворка и сторонних библиотек, они нередко содержат хотфиксы в контексте безопасности.

Передача данных по HTTPS

Обязательно настраивайте свой веб-сервер, будь то nginx или что другое, на HTTPS. SSL-сертификат можно получить бесплатно на letsencrypt.com. Библиотека certbot даже позволяет настроить автопродление серта.

Ограничение доступа к базе данных

Хотя Django ORM защищает от SQL-инъекций, дополнительные меры не повредят:

— Ограничьте права пользователя БД до необходимого минимума;
— Регулярно создавайте резервные копии и шифруйте данные;
— Используйте ORM Django.

Если необходимо использовать сырой SQL, спасет параметризация. В примере ниже драйвер БД экранирует значение username:

from django.db import connection

with connection.cursor() as cursor:
    cursor.execute("SELECT * FROM auth_user WHERE username = %s", [username])

Встроенные средства безопасности

Создатели проекта предоставляет множество встроенных механизмов безопасности:

— Добавьте django.middleware.security.SecurityMiddleware в список MIDDLEWARE;
— Настройте заголовки безопасности, такие как Content-Security-Policy, X-Content-Type-Options, X-Frame-Options.

Аутентификация

— Реализуйте многофакторную аутентификацию с помощью пакетов, таких как django-otp;
— Применяйте ролевую модель доступа для управления правами пользователей.

Полезные библиотеки | Misc

Ниже представлена слегка эклектичная, но полезная подборка тулов, прямо или косвенно повышающих безопасность вашего сайта:
— django-ratelimit ограничит частоту запросов;
— django-guardian управляет объектно-ориентированными разрешениями;
— SonarQube / semgrep.dev: автотестирует ваш проект на предмет эксплойтов (DevSecOps).

#безопасность #основы
@zen_of_python

Как работает развёртывание Python-приложений: от запроса до ответа

Зачем нужен gunicorn? А зачем — Nginx? Эти вопросы часто задают разработчики, впервые сталкивающиеся с деплоем Python-приложений. Может показаться, что веб-приложение — это просто код на Flask или Django, который запускается и принимает запросы. Но на практике между пользователем и вашим кодом выстраивается целая цепочка инфраструктурных компонентов, каждый из которых решает важную задачу. На схеме показан путь HTTP-запроса от клиента до конечного обработчика в приложении и обратно.

Accept: принимаем запрос

Когда пользователь открывает ваш сайт, он отправляет HTTP-запрос. Этот запрос в первую очередь встречается с внешним сервером — чаще всего это nginx. Его задача — понять, куда направить запрос: отдать ли статику, переписать URL, направить на конкретное приложение, или вовсе отклонить (например, по причине отсутствия авторизации). Он также может выполнять кэширование, сжатие и защищать от некоторых видов атак. Сюда же можно отнести балансировщики нагрузки и ingress-контроллеры в Kubernetes.

Translate: превращаем байты в Python

Следующий этап — перевод сетевого запроса в то, что понимает ваше Python-приложение. Это задача gunicorn или аналогичных серверов, поддерживающих WSGI (или ASGI, если речь о FastAPI и асинхронных приложениях). gunicorn создаёт рабочие процессы, слушает сокет, принимает соединения от nginx и передаёт их дальше в код Python. Он изолирует логику приложения от низкоуровневой сетевой части и обеспечивает масштабируемость.

Process: бизнес-логика и генерация ответа

Завершающий этап — сам Python-код во фреймворке (Django, Flask, FastAPI и пр.). Здесь выполняются проверки, обращения к БД, формируются HTML-страницы или JSON-ответы. Именно здесь происходит «магия» — добавление ценности, решение задач пользователей и реализация бизнес-логики.

#факт #основы
@zen_of_python

👀 — Если пришлось перечитать три раза

Краткий гайд про хэши для новичков

Хеширование — это фундаментальная концепция в Computer Science. В основе лежит идея односторонней функции, которая принимает на вход данные произвольного размера и возвращает выход фиксированной длины. Эта функция преобразует любые данные — будь то строка, число или файл — в уникальное значение фиксированной длины, называемое хешем. Это значение представляет собой последовательность битов, которая служит своего рода «отпечатком пальца» для исходных данных:

import hashlib

hash = hashlib.sha256()
hash.update(b'hello')
hashed_string = hash.hexdigest()

print(hashed_string) # 2cf24d......8b9824

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

— Проверка «девственности» передаваемых данных: при передаче данных по сети важно убедиться, что они не были изменены. Хеширование позволяет создать контрольную сумму, которая может быть использована для проверки целостности данных;

— Хранение паролей: вместо хранения оных в открытом виде их точно стоит обезопасить хешами;

— Хеширование используется для создания цифровых подписей, которые подтверждают подлинность и целостность сообщений или документов.


Многие из вас сталкивались с SSH-ключами для Git-репозиториев, причем с разными алгоритмами: MD5, SHA256. В отдельном посте поговорим об алгоритмах шифрования вроде RSA.

Когда мы создаем пару ключей (приватный + публичный), например с помощью:

ssh-keygen -t rsa -b 4096

То получаем приватный ключ, что хранится на локальной машине и используется для аутентификации. Также мы получаем публичный ключ и загружаем его на GitHub. Он не использует хеши для хранения или проверки самих публичных ключей, они проверяются напрямую, при помощи криптографических протоколов. Но вот где вступает в дело хеш:

GitHub (и SSH-клиенты в целом) используют хеши не для безопасности, а для удобной идентификации.

Когда мы смотрим отпечаток ключа, например:

ssh-keygen -lf ~/.ssh/id_rsa.pub

То получаем:

2048 SHA256:2f3b7A5Nk...xyz username@host (RSA)

Это и есть отпечаток ключа (fingerprint) — хеш публичного ключа. Он используется для подтверждения подлинности ключа.

#основы
@zen_of_python

Несколько способов ускорить ваш код.

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

tuple вместо list
Кортежи неизменяемы: они создаются один раз, занимают фиксированную память и оптимизируются самим интерпретатором. Списки же — динамический тип: их память часто переранее выделяется, они имеют более сложную внутреннюю структуру.

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


set и dict вместо list при частых проверках и поисках
— Поиск x in my_list — линейная операция (O(n));
— Проверка присутствия через my_set или my_dict — это хеш-таблица (O(1));

Если вам нужна частая проверка вхождений (фильтрация или поиск), выбирайте сет или словарь. Первый предпочтителен для уникальных элементов, второй — когда нужен быстрый доступ по ключу и хранение значений.

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

#основы
@zen_of_python

Немного безумные способы определения функций

Мы привыкли определять функции с помощью ключевого слова def. Однако Python как язык куда глубже и гибче, чем может показаться на первый взгляд. Существует несколько способов создать функцию — от практичных до откровенно абсурдных.

Lambda-функции — минимализм в действии

lambda позволяет создавать анонимные функции в одну строку. Это удобно, когда функция короткая и используется "на лету", например, в map() или filter(). Lambda-функции не могут содержать сложную логику или много выражений — только одно выражение, без return и вложенных блоков:

multiply_by_three = lambda x: x * 3
print(multiply_by_three(5)) 

Это удобно, но не стоит использовать lambda для сложной логики — теряется читаемость.


functools.partial

С помощью functools.partial можно создавать функции с уже предзаданными аргументами:

from functools import partial

def power(base, exponent):
    return base ** exponent

square = partial(power, exponent=2)
print(square(5))  # 25

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

Декораторы

Декораторы позволяют оборачивать функции и изменять их поведение — например, добавлять логирование, кэширование или даже модифицировать аргументы:

def print_result(fmt):
    def decorator(func):
        def wrapper(*args, **kwargs):
            result = func(*args, **kwargs)
            print(fmt.format(result))
            return result
        return wrapper
    return decorator

@print_result("Результат: {}")
def double(x):
    return x * 2

double(4)

Мощный инструмент, но при чрезмерном использовании может запутать читаемость кода.

Классы с методом __call__

В Python можно сделать объект вызываемым, определив метод __call__. Таким образом, вы можете создавать функции как объекты с состоянием:

class Greeter:
    def __call__(self, name):
        print(f"Hello, {name}!")

greet = Greeter()
greet("Bob")

Бонус — можно хранить состояние внутри объекта, например, счётчик вызовов.

exec()

exec() выполняет строку как код Python. Да, вы можете определять функции с его помощью.

code = '''
def add(x):
    return x + 10
'''
exec(code)
print(add(5))  # 15

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

eval()

eval() — ещё один способ выполнить строку кода, но только если это выражение, а не целый блок.

add = eval("lambda x: x + 10")
print(add(3))  # 13

Те же плюсы и минусы, что и у exec().

types.new_class

С помощью types.new_class() можно создавать callable-объекты (через `__call__`) на лету.

import types

def class_body(ns):
    ns['__call__'] = lambda self, x: x * 2

DynamicFunction = types.new_class("DynamicFunction")
class_body(DynamicFunction.__dict__)
func = DynamicFunction()
print(func(6))  # 12

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

#основы
@zen_of_python

​​Виды компьютерных сетей

Белый хакер разложил по полочкам, какие бывают топологии систем: кольцо, шина, звезда, WLAN, WAN.
Суперпонятная статья для новичков и не только: вы точно почерпнете для себя что-то новое.

#основы
@zen_of_python

Type Hinting vs. Type Checking vs. Data Validation: в чём разница?

Python — это язык с динамической типизацией («тип переменной определяется во время выполнения программы»). Это даёт большую гибкость, но одновременно приводит к ошибкам. Чтобы справляться с этим, разработчики используют три инструмента: аннотации типов, проверка типов и валидация данных. У каждого из них своя цель.


Type Hinting — подсказки, а не контроль

Аннотации типов (Type Hinting) — это способ добавить метаинформацию о типах данных, которую Python сам по себе не использует для исполнения кода:

def create_user(first_name: str, last_name: str, age: int) -> dict:
    return {"first_name": first_name, "last_name": last_name, "age": age}

Интерпретатор, однако, игнорирует эти аннотации при исполнении. Они нужны исключительно для разработчика и инструментов анализа.


Type Checking

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

### Как работает:

Для статической проверки используется внешний инструмент, например, MyPy

mypy your_script.py

Если передать строку вместо числа:

create_user("John", "Doe", "38")  # строка, а не int

MyPy выдаст ошибку:

error: Argument "age" to "create_user" has incompatible type "str"; expected "int"

Важное ограничение: не проверяет данные из внешних источников (например, API).


Data Validation

Валидация данных — это уже проверка во время исполнения программы. Она позволяет остановить программу, если входные данные не соответствуют ожиданиям:

if not isinstance(age, int):
    raise TypeError("Age must be an integer")

Ручная валидация быстро становится громоздкой. Здесь на помощь приходят библиотеки, такие как Pydantic.

Pydantic использует type hints для автоматической валидации данных. Пример с использованием @validate_call:

from pydantic import validate_call

@validate_call
def create_user(first_name: str, last_name: str, age: int) -> dict:
    return {"first_name": first_name, "last_name": last_name, "age": age}

Если передать некорректный тип:

create_user("John", "Doe", "38")  # строка

Вы получите подробное сообщение об ошибке:

1 validation error for create_user
age
  Input should be a valid integer (type=type_error.integer)

#основы
@zen_of_python

Комментарии в коде: зло или спасение?

Комментарий может не только объяснить код, но и быть бесячим. Грамотно написанные пометки значительно упрощают код-ревью. Кроме того, LLM'ки вроде GitHub Copilot используют комментарии как промты, а это сплошная экономия времени. В статье на Tproger порассуждали, где заканчивается польза и начинается вред от комментариев — и как найти правильный баланс.

#основы
@zen_of_python

Отслеживание неиспользуемых ключей в словаре Python

Словари — это фундаментальная структура данных, используемая для хранения пар «ключ-значение». В большинстве случаев мы просто читаем и записываем значения по ключам, не задумываясь о том, какие ключи были запрошены в процессе выполнения программы, а какие так и остались неиспользованными. Однако иногда в разработке возникает задача понять, какие ключи словаря так и не были использованы.

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

Без специальных инструментов проверить, какие ключи словаря не использовались, довольно сложно. Стандартный словарь в Python не хранит никакой информации о том, обращались ли к конкретному ключу.


Решения: словарь с учётом использования ключей

Для решения этой задачи можно создать класс-обёртку над обычным словарём, который при каждом запросе ключа будет отмечать этот ключ как «использованный».

Основные требования к такой структуре:

— При запросе значения по ключу отмечать ключ как использованный;
— Предоставлять метод, возвращающий ключи, к которым не обращались;
— Максимально просто и удобно использовать вместо обычного словаря.


Реализация: UsedDict

class UsedDict(dict):
    def __init__(self, *args, **kwargs):
        super().__init__(*args, **kwargs)
        self._used_keys = set()

    def __getitem__(self, key):
        self._used_keys.add(key)
        return super().__getitem__(key)

    def get_unused_keys(self):
        return set(self.keys()) - self._used_keys

— Наследуемся от стандартного dict, чтобы сохранить привычный интерфейс;
— При инициализации создаём пустое множество _used_keys, в котором будем хранить все ключи, к которым обращались;
— Переопределяем метод __getitem__, который вызывается при чтении значения по ключу mydict[key]. В этом методе сначала отмечаем ключ как использованный, а затем возвращаем значение;
— Добавляем метод get_unused_keys, который возвращает разницу между всеми ключами словаря и теми, которые использовались.

Пример использования:

config = UsedDict({
    "host": "localhost",
    "port": 8080,
    "debug": True,
    "timeout": 30
})

print(config["host"])  # используется
print(config["port"])  # используется

unused = config.get_unused_keys()
print("Неиспользованные ключи:", unused)
# Выведет: Неиспользованные ключи: {'debug', 'timeout'}

#основы

Упорядочены ли словари в Python?

Что значит «упорядоченный»?

Когда говорят об упорядоченности, важно понять контекст. Например:

— Если просят расставить коробки, порядок — по размеру;
— Если вы в очереди – порядок по времени прихода.

Если структура упорядоченная, она в каком-то смысле сохраняет свой внутренний порядок. А как со словарями?


Исторический обзор

До Python 3.6: словари не сохраняли никакого порядка при выводе или переборе. Параметры key: value могли выводиться в совершенно произвольном порядке.

Начиная с Python 3.6 словари начали сохранять порядок вставки — но это считалось технической деталью реализации, а не официально гарантированным свойством. Позднее это стало частью официальной спецификации языка.


Это значит, что словари упорядочены?

Частично — да:: словари сохраняют порядок добавления элементов. Это позволяет, например, при переборе ключей получать их в том же порядке, что при вставке.

Важное «но»: порядок не влияет на сравнение словарей:

a = {"x": 1, "y": 2}
b = {"y": 2, "x": 1}
a == b  # True

То есть, равенство проверяется по парам ключ‑значение, а не по их порядку (в отличие от списка).


Почему обычный dict сравнивается по содержанию, а не по порядку?

— Оптимизация: словари предназначены для быстрой работы по ключу (хэширование);
— Благодаря «разделённой таблице» (split-table) в реализации CPython, словарь может одновременно эффективно хранить и порядке вставки, и хэш-структуру.

#основы
👌 — Если всё по красоте

TypedDict | Куда, зачем

Для тех, кто стремится писать поддерживаемый код, существует TypedDict («Типизированный словарь»). В этом посте разберём, зачем нужен, как правильно использовать и какие возможности открывает.

TypedDict — это специальный тип данных, что позволяет создавать словари с явно заданными типами для ключей и значений. Таким образом, вы можете описать структуру словаря, как будто это объект с фиксированными полями.

from typing import TypedDict

class User(TypedDict):
    name: str
    age: int
    email: str

В обычных словарях Python ключи и значения могут быть абсолютно любыми, и это даёт большую гибкость, но вместе с тем усложняет контроль и проверку данных. TypedDict позволяет добавить статическую типизацию к словарям, тем самым снизить вероятность неожиданных ситуаций с вашими экземплярами.

В примере выше мы создаем класс User, который наследуется от TypedDict. Теперь словари типа User должны иметь ключи name, age и email с типами str, int и str соответственно.

Теперь при создании экземпляра:

user: User = {
    "name": "Alice",
    "age": 30,
    "email": "[email protected]"
}

если в словаре отсутствует обязательный ключ или тип значения не совпадает, современные инструменты статической типизации (например, mypy) выдадут ворнинг.


Опциональные ключи

Бывает, что не всегда все ключи словаря на месте. В TypedDict их можно сделать необязательными (total=False):

class User(TypedDict, total=False):
    nickname: str
    bio: str

#основы
@zen_of_python

pip vs. pip3 | Что выбрать?

Если вам вдруг стало очень важно понимать различие между этими менеджерами зависимостей, то все просто. Основное различие — это «принадлежность» версиям Python 2 или 3:
- pip — это менеджер пакетов по умолчанию для Python 2 / 3 (где «двойка» не установлена;
- pip3 — это явно указанный менеджер пакетов для Python 3.

Если у вас установлен только Python 3, pip и pip3 будут работать одинаково.

Как проверить, какая версия связана с pip

pip --version # pip 20.0.2 from /usr/lib/python2.7/site-packages/pip (python 2.7)

pip3 --version # pip3 21.2.4 from /usr/lib/python3.8/site-packages/pip (python 3.8)

#основы
@zen_of_python

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

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.
#основы

Почему вам стоит попробовать 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
…текст транскрипта…

#основы

__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`);
— При работе с устаревшими инструментами;
— При построении плоского интерфейса пакета;
— Для поддержки специфичных путей и логики импорта.

#основы

Построчная безопасность (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);

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

#основы

Почему некоторые исключения не попадают в лог и как это исправить

logging — это уже целый стандарт записи ошибок в Python. Ваше приложение запускается, сообщения попадают в лог. Но вдруг в продакшене приложение внезапно «падает», а в логах — тишина. Знакомо?

Если да — вы столкнулись с одной из малозаметных, но опасных особенностей Python — «непойманные исключения» (uncaught exceptions).

В этом посте мы разберёмся, почему такое вообще случается, как надежно логировать любые исключения.

Рассмотрим следующий код:

import logging

logger = logging.getLogger(__name__)
logging.basicConfig(filename="output.log", level=logging.INFO)

logger.info("Application started")

1 / 0  # деление на ноль

В консоли вы увидите traceback:

Traceback (most recent call last):
...
ZeroDivisionError: division by zero

А в output.log будет только:

INFO:__main__:Application started

Никакой информации об ошибке. И это сгенерирует вам часы работы.

Почему так происходит?

Библиотека logging в Python не логирует ошибки сама по себе: она просто предоставляет инструменты для записи. Если программа падает из-за исключения, и это исключение не обрабатывается в try / except, то встроенный модуль никак не участвует в этом процессе. Потому что стандартный Python-интерпретатор выводит непойманные исключения напрямую в stderr, минуя logging.

Плохое (но распространённое) решение

Один из способов «поймать всё» — обернуть main() в try / except:

def main():
    logger.info("Application started")
    1 / 0

try:
    main()
except Exception as e:
    logger.exception("Unhandled exception:")

Это сработает: logger.exception() запишет ошибку и трейсбек. Но есть минусы:

— Вы можете пропустить системные исключения (KeyboardInterrupt и проч., если ловите Exception, а не BaseException;
— Такой код трудно масштабировать: оборачивать каждый main() в каждом скрипте — дублирование;
— Это маскирует архитектурные проблемы: непойманные исключения — это чаще всего баг, а не ожидаемое поведение.


Правильное решение: sys.excepthook

Python дает глобально обрабатывать непойманные исключения — sys.excepthook:

import sys
import logging

logger = logging.getLogger(__name__)
logging.basicConfig(filename="output.log", level=logging.INFO)

def handle_uncaught_exception(exc_type, exc_value, exc_traceback):
    logger.critical(
        "Uncaught exception. Application will terminate.",
        exc_info=(exc_type, exc_value, exc_traceback)
    )

sys.excepthook = handle_uncaught_exception

logger.info("Application started")

1 / 0

Теперь, если запустить скрипт:

— В output.log появится подробный трейсбек ошибки;
— Вы будете уверены, что даже критические ошибки попадут в лог, прежде чем приложение завершится.

Когда в Python возникает исключение, и его никто не перехватывает, вызывается sys.excepthook(type, value, traceback). По умолчанию она просто печатает детали в stderr. Но вы можете управлять процессом:

— Логировать ошибки;
— Отправлять оповещения (например, в Telegram или на почту);
— Снимать дампы или делать очистку.

#основы