Zen of Python
Полный Дзен Пайтона в одном канале Разместить рекламу: @tproger_sales_bot Правила общения: https://tprg.ru/rules Другие каналы: @tproger_channels Сайт: https://tprg.ru/site Регистрация в перечне РКН: https://tprg.ru/xZOL
Ko'proq ko'rsatish📈 Telegram kanali Zen of Python analitikasi
Zen of Python (@zen_of_python) Rus til segmentidagi kanali faol ishtirokchi. Hozirda hamjamiyat 18 953 obunachidan iborat bo'lib, Texnologiyalar & Aralashmalar toifasida 6 786-o'rinni va Rossiya mintaqasida 34 781-o'rinni egallagan.
📊 Auditoriya ko‘rsatkichlari va dinamika
невідомо sanasidan buyon loyiha tez o‘sib, 18 953 obunachiga ega bo‘ldi.
27 Avgust, 2026 dagi oxirgi ma’lumotlarga ko‘ra kanal barqaror faollikka ega. Oxirgi 30 kunda obunachilar soni -157 ga, so‘nggi 24 soatda esa 7 ga o‘zgardi va umumiy qamrov yuqori darajada qolmoqda.
- Tasdiqlash holati: Tasdiqlanmagan
- Jalb etish (ER): Auditoriya o‘rtacha 12.56% darajada jalb etiladi. Nashrdan keyingi dastlabki 24 soatda kontent odatda umumiy obunachilar sonining 6.30% ini tashkil etuvchi reaksiyalarni to‘playdi.
- Post qamrovi: Har bir post o‘rtacha 2 381 marta ko‘riladi; birinchi sutkada odatda 1 195 ta ko‘rish yig‘iladi.
- Reaksiyalar va o‘zaro ta’sir: Auditoriya faol: har bir postga o‘rtacha 5 ta reaksiya keladi.
- Tematik yo‘nalishlar: Kontent github, rust, pip, api, install kabi asosiy mavzularga jamlangan.
📝 Tavsif va kontent siyosati
Muallif resursni shaxsiy fikrni ifoda etish maydoni sifatida ta’riflaydi:
“Полный Дзен Пайтона в одном канале
Разместить рекламу: @tproger_sales_bot
Правила общения: https://tprg.ru/rules
Другие каналы: @tproger_channels
Сайт: https://tprg.ru/site
Регистрация в перечне РКН: https://tprg.ru/xZOL”
Yuqori yangilanish chastotasi (oxirgi ma’lumot 28 Avgust, 2026 da olingan) sababli kanal doimo dolzarb va katta qamrovli bo‘lib qoladi. Analitika auditoriya kontent bilan faol hamkorlik qilishini, uni Texnologiyalar & Aralashmalar toifasidagi muhim ta’sir nuqtasiga aylantirishini ko‘rsatadi.
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`);
— При работе с устаревшими инструментами;
— При построении плоского интерфейса пакета;
— Для поддержки специфичных путей и логики импорта.
#основы