Zen of Python
Полный Дзен Пайтона в одном канале Разместить рекламу: @tproger_sales_bot Правила общения: https://tprg.ru/rules Другие каналы: @tproger_channels Сайт: https://tprg.ru/site Регистрация в перечне РКН: https://tprg.ru/xZOL
Mostrar más📈 Análisis del canal de Telegram Zen of Python
El canal Zen of Python (@zen_of_python) en el segmento lingüístico de Ruso es un actor destacado. Actualmente la comunidad reúne a 18 953 suscriptores, ocupando la posición 6 786 en la categoría Tecnologías y Aplicaciones y el puesto 34 781 en la región Rusia.
📊 Métricas de audiencia y dinámica
Desde su creación el невідомо, el proyecto ha mostrado un crecimiento acelerado, reuniendo a 18 953 suscriptores.
Según los últimos datos del 27 agosto, 2026, el canal mantiene una actividad estable. En los últimos 30 días la variación de miembros fue de -157, y en las últimas 24 horas de 7, conservando un alto alcance.
- Estado de verificación: No verificado
- Tasa de interacción (ER): El promedio de interacción de la audiencia es 12.56%. Durante las primeras 24 horas tras publicar, el contenido suele obtener 6.30% de reacciones respecto al total de suscriptores.
- Alcance de las publicaciones: Cada publicación recibe en promedio 2 381 visualizaciones. En el primer día suele acumular 1 195 visualizaciones.
- Reacciones e interacción: La audiencia responde de forma activa: el promedio de reacciones por publicación es 5.
- Intereses temáticos: El contenido se centra en temas clave como github, rust, pip, api, install.
📝 Descripción y política de contenido
El autor describe el recurso como un espacio para expresar opiniones subjetivas:
“Полный Дзен Пайтона в одном канале
Разместить рекламу: @tproger_sales_bot
Правила общения: https://tprg.ru/rules
Другие каналы: @tproger_channels
Сайт: https://tprg.ru/site
Регистрация в перечне РКН: https://tprg.ru/xZOL”
Gracias a la alta frecuencia de actualizaciones (últimos datos recibidos el 28 agosto, 2026), el canal mantiene la vigencia y un amplio alcance. La analítica demuestra que la audiencia interactúa activamente con el contenido, lo que lo convierte en un punto de referencia dentro de la categoría Tecnologías y Aplicaciones.
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`);
— При работе с устаревшими инструментами;
— При построении плоского интерфейса пакета;
— Для поддержки специфичных путей и логики импорта.
#основы