Zen of Python
Полный Дзен Пайтона в одном канале Разместить рекламу: @tproger_sales_bot Правила общения: https://tprg.ru/rules Другие каналы: @tproger_channels Сайт: https://tprg.ru/site Регистрация в перечне РКН: https://tprg.ru/xZOL
إظهار المزيد📈 نظرة تحليلية على قناة تيليجرام Zen of Python
تُعد قناة Zen of Python (@zen_of_python) في القطاع اللغوي الروسية لاعباً نشطاً. يضم المجتمع حالياً 18 957 مشتركاً، محتلاً المرتبة 6 786 في فئة التكنولوجيات والتطبيقات والمرتبة 34 781 في منطقة روسيا.
📊 مؤشرات الجمهور والحراك
منذ تأسيسه في невідомо، حقق المشروع نمواً سريعاً وجمع 18 957 مشتركاً.
بحسب آخر البيانات بتاريخ 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) تحافظ القناة على حداثتها ومستوى وصول مرتفع. وتُظهر التحليلات تفاعلاً نشطاً من الجمهور، ما يجعلها نقطة تأثير مهمة ضمن فئة التكنولوجيات والتطبيقات.
self: простейшее объяснение
Если вы только начинаете изучать Python, то почти наверняка уже столкнулись с self. В этом лонгриде мы разберемся, что это и с чем это едят.
self — это ссылка на объект
Ключевое слово self используется в методах классов. Оно всегда указывает на текущий экземпляр класса, через который происходит обращение к данным и методам.
class Employee:
def set_salary(self, value):
self.salary = value
e = Employee()
e.set_salary(2000)
print(e.salary)
Когда вы создаёте объект, Python автоматически передаёт этот объект первым аргументом в метод. Принято называть его self, хотя технически вы можете использовать любое имя.
🔘 Создаётся класс Employee с методом set_salary. Этот метод принимает два аргумента:
— self — сам объект;
— value — значение, которое мы хотим установить.
🔘 Внутри метода выполняется присваивание:
self.salary = value
Это значит, что у конкретного объекта e создаётся атрибут salary, которому присваивается переданное значение.
🔘 Далее создаём объект:
e = Employee()
🔘 Устанавливаем зарплату:
e.set_salary(2000)
На самом деле Python преобразует этот вызов в:
Employee.set_salary(e, 2000)
🔘 Проверяем результат:
print(e.salary) # 2000
Почему без self не обойтись?
self позволяет объекту хранить собственные данные. Каждый экземпляр класса имеет свой набор атрибутов, и именно через self мы к ним обращаемся.
Например, если создать двух сотрудников:
e1 = Employee()
e2 = Employee()
e1.set_salary(2000)
e2.set_salary(3000)
print(e1.salary) # 2000
print(e2.salary) # 3000
У каждого объекта будет своя зарплата.
#инструмент
@zen_of_pythoncruft update, чтобы подтягивать изменения из шаблона по мере его развития. Инструмент умеет проверять, актуален ли проект относительно шаблона, и позволяет автоматически применять обновления через CI-конвейеры. Это отличный способ избежать дублирования кода и облегчить поддержку множества проектов, основанных на одном шаблоне.
#инструмент
@zen_of_python
def count_titles(titles: list[str]) -> int:
return len(titles)
Здесь -> int говорит: «ожидается, что функция вернёт int». Аннотации опциональны и сами по себе ничего в рантайме не проверяют — это метаданные.
Краткая история оператора
Идея аннотаций функций впервые появилась в PEP 3107 (Function Annotations), который ввёл возможность добавлять произвольные метаданные к параметрам и к возвращаемому значению. На базе этой синтаксики PEP 484 затем ввёл систему типовых подсказок (type hints) для Python, сделав их стандартной практикой для тех, кто хочет статической проверки типов. Все эти дополнения остались опциональными — сам интерпретатор не будет выбрасывать ошибки, если аннотации не совпадают с фактическим типом во время выполнения.
Простой пример:
import random
def get_game_recommendation(titles: list[str]) -> str:
return random.choice(titles)
games = ["Minecraft", "Cyberpunk 2077", "The Witcher 3", "Elden Ring"]
recommendation = get_game_recommendation(games)
print(f"Рекомендуемая игра: {recommendation}") # Например, Minecraft
print(f"Тип возвращаемого значения: {type(recommendation).__name__}") # str
Что происходит, если функция возвращает другой тип?
Python сам по себе не будет проверять, совпадает ли реальный возвращаемый тип с аннотацией — код просто выполнится. Но когда вы используете статический анализатор типов (например, mypy) или линтер, несоответствие будет обнаружено и выведет предупреждение / ошибку. Это ключевая идея: аннотации дают выгоду при статической проверке, CI и чтении кода, но не изменяют семантику программы во время выполнения.
Какие типы можно указывать после ->?
Почти любые:
🔘 простые встроенные (int, str, bool),
🔘 коллекции (list[str], dict[str, int]),
🔘 собственные классы и проч.
Где ещё применяются стрелки и аннотации?
Хотя наиболее часто -> встречается в объявлениях функций, аннотации — это часть более широкой системы типизации в Python. Типы используются для:
🔘 аннотаций параметров функций;
🔘 переменных и атрибутов классов (PEP 526);
🔘 аннотаций методов, Callable, Protocol и т.д.;
🔘 документации и автодополнения в IDE.
Инструменты типа mypy, pyright, IDE (PyCharm, VS Code) и линтеры используют аннотации, чтобы находить ошибки и улучшать подсказки.
Ограничения и подводные камни
🔘 Аннотации не выполняются: они не гарантия корректности в рантайме;
🔘 Сложные типы для сложной структуры данных или динамических конструкций типы могут стать громоздкими; иногда приходится балансировать читабельность и строгость;
#основы
@zen_of_pythonDocker (Контейнеризация) 🔘 Представьте Docker как транспортный контейнер для софта. 🔘 Он упаковывает код, библиотеки и зависимости так, чтобы приложение одинаково работало в любой среде. 🔘 Плюсы: портативность, изоляция и одинаковое поведение в dev-, staging- и production-средах. Kubernetes (Оркестрация) 🔘 Когда контейнеров становится много, нужен управляющий. 🔘 Kubernetes — это как портовая служба, которая управляет контейнерами: масштабирует, перезапускает, балансирует нагрузку. 🔘 Обеспечивает балансировку нагрузки, масштабирование, поэтапные обновления и самовосстановление контейнерных приложений. CI/CD (Непрерывная интеграция и доставка) 🔘 CI — это как проверка каждого продукта перед отправкой с завода: тесты запускаются автоматически при каждом пуше кода. 🔘 CD — это система доставки: одобренные изменения автоматически едут в production. 🔘 Плюсы: более быстрые релизы, меньше багов, проще командная работа. Аналогия 🔘 Docker — Запечатанная коробка с вашим товаром. 🔘 Kubernetes — Логистическая компания, которая организует и доставляет все коробки по назначению. 🔘 CI/CD — Конвейер, на котором коробки непрерывно отправляются дальше без задержек.
datetime, поддерживает:
— Вычисление «следующего X»: удобно находим даты следующего понедельника или последней недели месяца;
— Относительные дельты: вычисляем разницу между двумя датами не только в секундах, но и в понятных календарных единицах (например, «2 месяца и 5 дней»);
— Рекуррентные даты (повторяющиеся события)
Поддерживается генерация серий дат по очень гибким правилам, расширяющим стандарт iCalendar (например: «каждый второй вторник месяца до конца года») и многое другое.
Еще бы русский язык поддерживала, цены бы не было!
#инструмент
@zen_of_python
# После добавления нового кода
def new_feature():
unused_var = "not used" # Линтер найдет неиспользуемую переменную
return "feature"
⚡️ Проверка совместимости
# После изменения импортов
from new_module import new_function
# Линтер проверит, существует ли new_function
⚡️ Соблюдение стандартов
# После рефакторинга
class MyClass:
def __init__(self):
self.very_long_attribute_name_that_should_be_shorter = None
# Линтер предложит сократить имя
⚡️ Проблемы безопасности
import subprocess
user_input = input("Enter command: ")
subprocess.run(user_input, shell=True) # Линтер предупредит о SQL injection
⚡️ Неэффективный код
# Неэффективно
my_list = []
for i in range(1000):
my_list.append(i)
# Линтер может предложить list comprehension
my_list = [i for i in range(1000)]
Настройка линтера
Обычно линтер настраивается через файлы конфигурации:
# pyproject.toml
[tool.ruff]
line-length = 88 # Максимальная длина строки
target-version = "py38" # Версия Python
Мы можем тонко настраивать, каким именно правилам следовать:
[tool.ruff.lint]
select = ["E", "F", "W", "C90", "I", "N", "UP", "YTT", "S", "BLE", "FBT", "B", "A", "COM", "C4", "DTZ", "T10", "EM", "EXE", "FA", "ISC", "ICN", "G", "INP", "PIE", "T20", "PYI", "PT", "Q", "RSE", "RET", "SLF", "SLOT", "SIM", "TID", "TCH", "INT", "ARG", "PTH", "TD", "FIX", "ERA", "PD", "PGH", "PL", "TRY", "FLY", "NPY", "AIR", "PERF", "FURB", "LOG", "RUF"]
ignore = ["E501", "S101", "PLR0913", "PLR0912", "PLR0915"]
Классические линтеры
🔘Pylint
🔘ruff
🔘Flake8
🔘mypy
🔘black
Пользователи Cursor, возможно, обратили внимание на завтозапуск линтера после практически каждого внесенного изменения. Эта IDE не отдает предпочтения какому-то конкретному инструменту, но запускает несколько из них.
Список правил ruff с детализацией в доках
#основы
@zen_of_python