Zen of Python
Полный Дзен Пайтона в одном канале Разместить рекламу: @tproger_sales_bot Правила общения: https://tprg.ru/rules Другие каналы: @tproger_channels Сайт: https://tprg.ru/site Регистрация в перечне РКН: https://tprg.ru/xZOL
显示更多📈 Telegram 频道 Zen of Python 的分析概览
频道 Zen of Python (@zen_of_python) 俄语 语言赛道中的 是活跃参与者。目前社区聚集了 18 953 名订阅者,在 技术与应用 类别中位列第 6 786,并在 俄罗斯 地区排名第 34 781 位。
📊 受众指标与增长动态
自 невідомо 创建以来,项目保持高速增长,吸引了 18 953 名订阅者。
根据 27 八月, 2026 的最新数据,频道保持稳定运转。过去 30 天订阅人数变化为 -157,过去 24 小时变化为 7,整体触达仍然可观。
- 认证状态: 未认证
- 互动率 (ER): 平均受众互动率为 12.56%。内容发布后 24 小时内通常能获得 6.30% 的反应,占订阅者总量。
- 帖子覆盖: 每篇帖子平均可获得 2 381 次浏览,首日通常累积 1 195 次浏览。
- 互动与反馈: 受众积极参与,单帖平均反应数为 5。
- 主题关注点: 内容集中在 github, rust, pip, api, install 等核心主题上。
📝 描述与内容策略
作者将该频道定位为表达主观观点的平台:
“Полный Дзен Пайтона в одном канале
Разместить рекламу: @tproger_sales_bot
Правила общения: https://tprg.ru/rules
Другие каналы: @tproger_channels
Сайт: https://tprg.ru/site
Регистрация в перечне РКН: https://tprg.ru/xZOL”
凭借高频更新(最新数据采集于 28 八月, 2026),频道始终保持新鲜度与高覆盖。分析显示受众积极互动,使其成为 技术与应用 类别中的关键影响点。
compression.zstd для работы с алгоритмом Zstandard прямо «из коробки» и многое другое.
#факт
@zen_of_pythonlogging — это уже целый стандарт записи ошибок в 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 или на почту);
— Снимать дампы или делать очистку.
#основы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);
Теперь пользователь не сможет вставить или изменить строку, если не имеет на это права.
#основыleak_checker(), который можно легко встроить в тесты или отладочные блоки. Отличный выбор для тех, кто хочет контролировать потребление памяти без тяжёлых инструментов.
Репозиторий проекта
#инструмент
@zen_of_python__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`);
— При работе с устаревшими инструментами;
— При построении плоского интерфейса пакета;
— Для поддержки специфичных путей и логики импорта.
#основы