PytStart | Программирование на Python

📈 Вышел из `range()`: быстрые числовые циклы с numpy и numba Все пишут циклы с range(), но на больших данных они тормозят как бабушкин компьютер. Для числодробилки есть два монстра: numpy (векторизация) и numba (JIT-компиляция). Разбираемся, как ускориться в десятки раз и не сойти с ума. ⚡️ Проблема: обычный цикл тормозит

    
        import time

def sum_squares(n):
    total = 0
    for i in range(n):
        total += i * i
    return total

start = time.time()
result = sum_squares(10_000_000)
print(f"Python: {time.time() - start:.2f} сек")
# Python: 0.85 сек (примерно){}
    

➡️ 10 миллионов итераций — почти секунда. А если нужно обработать гигабайты данных? Можно и чай сходить выпить. ✅ Numpy: думаем векторами Numpy выполняет операции над целыми массивами на C, без питоновских циклов.

    
        import numpy as np

def np_sum_squares(n):
    arr = np.arange(n)          # массив [0, 1, 2, ..., n-1]
    return np.sum(arr * arr)     # всё сразу

start = time.time()
result = np_sum_squares(10_000_000)
print(f"Numpy: {time.time() - start:.2f} сек")
# Numpy: 0.05 сек (в 17 раз быстрее){}
    

➡️ Векторизация — когда операция применяется ко всем элементам сразу. Никаких циклов, чистая скорость. 🔍 Numba: JIT-компиляция для сложной логики А если логика не векторизуется (условия, рекурсия)? Numba компилирует питоновский код в машинный прямо перед выполнением.

    
        from numba import njit

@njit
def nb_sum_squares(n):
    total = 0
    for i in range(n):
        total += i * i
    return total

start = time.time()
result = nb_sum_squares(10_000_000)
print(f"Numba: {time.time() - start:.2f} сек")
# Numba: 0.02 сек (в 42 раза быстрее){}
    

➡️ Просто добавил @njit — и код полетел. Магия. 🚀 Когда что брать

    
        # Numpy — массовые операции
arr = np.array([1, 2, 3, 4, 5])
print(arr.mean())  # 3.0
print(arr * 2)     # [2 4 6 8 10]

# Numba — сложная логика с условиями
@njit
def conditional_sum(arr):
    total = 0
    for x in arr:
        if x > 0:
            total += x
    return total{}
    

📦 Практический пример: обработка изображения

    
        import numpy as np
from numba import njit

img = np.random.randint(0, 255, (1000, 1000), dtype=np.uint8)

@njit
def filter_nb(img):
    h, w = img.shape
    result = np.zeros((h, w), dtype=np.uint8)
    for i in range(1, h-1):
        for j in range(1, w-1):
            val = (int(img[i-1][j]) + img[i+1][j] + img[i][j-1] + img[i][j+1]) // 4
            result[i][j] = val
    return result

# filter_nb(img) ~0.1 сек (в 50 раз быстрее чистого Python){}
    

➡️ Двойной цикл по миллиону пикселей? Numba справляется играючи. 🗣️ Запомни: Если в коде есть тяжёлый цикл с числами — numpy для массовки, numba для сложной логики.

На Stepik запустили курс «От новичка к уверенности в коде на Python» Курс создан для новичков, которым важно не заучить команды, а понять логику. Наглядные схемы и визуальные разборы показывают, что происходит внутри программы и как она работает Много практики, понятные объяснения решений не дадут застрять на теории. Материал предлагает вам не иллюзию знаний, а ощущение контроля: вы ясно видите как из нескольких строк кода рождается работающая программа Что внутри: ✅переменные и типы данных ✅условия и логика программ ✅циклы и рекурсия ✅функции и работа с вводом данных ✅списки, словари и множества ✅базовое ООП ✅работа с библиотеками Python ✅десятки задач и упражнений Эти знания фундамент для написания простых ботов и автоматизации задач Скидка 25%, действует 48 часов 🔗Пройти курс на Stepik

🧩 ABC vs Protocols: выбираем интерфейс правильно В Python два способа описать контракт: абстрактные базовые классы (ABC) и протоколы. Оба говорят "у объекта должен быть метод X", но работают по-разному. ⚡️ ABC: явное наследование

    
        
from abc import ABC, abstractmethod

class Drawer(ABC):
    @abstractmethod
    def draw(self):
        pass

class Circle(Drawer):
    def draw(self):
        return "🔴"

def show(obj: Drawer):
    print(obj.draw())

show(Circle())  # ✅
show("строка")  # ❌ mypy ругнётся{}
    

➡️ Класс обязан наследоваться от Drawer. Жёстко, зато явно. ✔️ Protocol: структурная типизация

    
        
from typing import Protocol

class Drawer(Protocol):
    def draw(self): ...

class Circle:
    def draw(self):
        return "🔴"

class Square:
    def draw(self):
        return "⬛️"

def show(obj: Drawer):
    print(obj.draw())

show(Circle())  # 🔴
show(Square())  # ⬛️{}
    

➡️ Наследование не нужно. Если есть метод draw - объект подходит. 🎯 Когда что брать?

    
        
# ABC - когда нужна общая логика
class Logger(ABC):
    def log(self, msg):
        print(f"[{self.prefix()}] {msg}")
    
    @abstractmethod
    def prefix(self): ...

# Protocol - когда нужна гибкость
class Fetcher(Protocol):
    async def fetch(self, url): ...
# Любой класс с fetch подойдёт - aiohttp, httpx, мок для тестов{}
    

🔍 Живой пример: обработчики событий

    
        
from typing import Protocol

class Handler(Protocol):
    def handle(self, event: dict): ...

class UserHandler:
    def handle(self, event):
        print(f"Пользователь: {event}")

class OrderHandler:
    def handle(self, event):
        print(f"Заказ: {event}")

def process(events, handler: Handler):
    for event in events:
        handler.handle(event)

process([{"id": 1}], UserHandler())
process([{"order": 123}], OrderHandler())  # оба работают{}
    

🧪 Runtime-проверка если очень надо

    
        
from typing import Protocol, runtime_checkable

@runtime_checkable
class Drawer(Protocol):
    def draw(self): ...

print(isinstance(Circle(), Drawer))  # True{}
    

➡️ isinstance работает, но проверяет только наличие метода, не типы аргументов. 🗣️ Запомни: ABC - для жёсткой архитектуры и общей логики. Protocol - для гибкости и утиной типизации. В современном Python протоколы используют чаще - они не заставляют лезть в наследование, если объект и так умеет что нужно.

Бесплатная конференция по PostgreSQL Регистрируйся на бесплатную конференцию по PostgreSQL — 19.03.2026.📅 Эксперты расскажут о разработке, администрировании и новинках мира Postgres. ✅ Бесплатное участие ✅ Опытные спикеры ✅ 25+ тематических докладов ✅ Рабочие кейсы Каждый участник получает именной Сертификат участника мероприятия. Одни из немногих спикеров конференции: — Андрей Бородин PostgreSQL Major contributor, руководитель подразделения разработки РСУБД с открытым исходным кодом Yandex Cloud — Родион Хабибов DevOps-инженер «СберСервис» — Андрей Овчаренко Руководитель отдела Java-разработки Московской биржи ... и многие другие. Регистрируйся, будет интересно! И бесплатно! Зарегистрироваться #реклама 16+ pgbootcamp.ru О рекламодателе

🛠 Dependency Injection в Python: зачем и как без фреймворков Ты когда-нибудь писал класс, который внутри создаёт объекты, а потом не мог его протестировать? Или менял базу данных, а переписывать приходилось полпроекта? Dependency Injection (DI) лечит эту боль. Всё, что нужно — передавать зависимости через конструктор. ⚡️ Базовый пример: жёсткая связь vs внедрение Плохо:

    
        class UserService:
    def __init__(self):
        self.db = PostgreSQLDatabase()  # Сам создаёт зависимость

    def get_user(self, user_id):
        return self.db.query(f"SELECT * FROM users WHERE id = {user_id}"){}
    

👉 Класс привязан к конкретной БД. Сменить на MySQL? Править код. Тестировать? Только с настоящей БД. Хорошо:

    
        class UserService:
    def __init__(self, database):  # Получает готовую зависимость
        self.db = database

    def get_user(self, user_id):
        return self.db.query(f"SELECT * FROM users WHERE id = {user_id}")

# Теперь можно подставить любую БД с методом query
service = UserService(PostgreSQLDatabase()){}
    

👉 Класс ничего не знает о реализации. Гибкость и тестируемость растут. ✔️ Тестировать теперь легко

    
        class MockDB:
    def query(self, sql):
        return {"id": 1, "name": "Тест"}

def test_get_user():
    service = UserService(MockDB())
    user = service.get_user(1)
    assert user["name"] == "Тест"{}
    

👉 Никакой реальной БД, тесты летают. 🔍 Простой DI-контейнер своими руками Когда зависимостей много, таскать их вручную надоедает. Сделаем простой контейнер:

    
        class Container:
    def __init__(self):
        self._services = {}

    def register(self, name, builder):
        self._services[name] = builder

    def resolve(self, name):
        builder = self._services.get(name)
        if not builder:
            raise ValueError(f"Service {name} not found")
        return builder(self)

# Настраиваем контейнер
container = Container()
container.register('db', lambda c: PostgreSQLDatabase())
container.register('user_service', lambda c: UserService(c.resolve('db')))

# Получаем готовый сервис со всеми зависимостями
user_service = container.resolve('user_service'){}
    

👉 Контейнер сам создаёт объекты, подставляя нужные зависимости. Добавил новый сервис — просто опиши его в регистрации. 🧪 Фабрики и зависимости с параметрами Иногда объекту нужны не только сервисы, но и параметры (например, строка подключения). Контейнер легко расширить:

    
        container.register('db', lambda c: PostgreSQLDatabase(c.resolve('config').db_url))
container.register('config', lambda c: Config.from_env()){}
    

👉 Теперь можно строить любые графы зависимостей. 🚀 Практический кейс: сервис с репозиторием и логгером

    
        class UserRepo:
    def __init__(self, db):
        self.db = db
    def get(self, user_id):
        return self.db.query(...)

class Logger:
    def log(self, msg):
        print(f"[LOG] {msg}")

class UserService:
    def __init__(self, repo, logger):
        self.repo = repo
        self.logger = logger

    def get_user(self, user_id):
        self.logger.log(f"Fetching user {user_id}")
        return self.repo.get(user_id)

# Собираем через контейнер
container.register('db', lambda c: PostgreSQLDatabase())
container.register('repo', lambda c: UserRepo(c.resolve('db')))
container.register('logger', lambda c: Logger())
container.register('user_service', lambda c: UserService(c.resolve('repo'), c.resolve('logger')))

service = container.resolve('user_service'){}
    

👉 Все зависимости собраны в одном месте, легко подменить любую часть для тестов или замены реализации. 🗣️ Запомни: Dependency Injection — это принцип «не создай, а получи».

🎯 asyncio.Semaphore: ограничиваем число одновременных запросов к API Ты делаешь 1000 асинхронных запросов к API, а сервер отвечает 429-й ошибкой? Без ограничения одновременных запросов ты рискуешь получить бан или перегрузить удаленный сервис. Semaphore - это страж, который пропускает только N корутин одновременно. ⚡️ Базовый пример: не больше 3 запросов в секунду

    
        
import asyncio
import aiohttp

async def fetch(url, session, semaphore):
    async with semaphore:  # Ждем, пока не освободится слот
        async with session.get(url) as response:
            return await response.text()

async def main():
    semaphore = asyncio.Semaphore(3)  # Не более 3 одновременных запросов
    urls = ['https://api.example.com/item/{}'.format(i) for i in range(20)]
    
    async with aiohttp.ClientSession() as session:
        tasks = [fetch(url, session, semaphore) for url in urls]
        results = await asyncio.gather(*tasks)
    print(f'Получено {len(results)} ответов')

asyncio.run(main()){}
    

➡️ async with semaphore блокирует выполнение, если все слоты заняты. Как только один запрос завершается, слот освобождается и пускает следующий. ✅ Semaphore как контекстный менеджер в задаче Иногда нужно ограничить не всю функцию целиком, а только критическую секцию:

    
        
async def bounded_fetch(url, session, semaphore):
    # Тут можно делать предварительную обработку без семафора
    async with semaphore:  # только сам запрос ограничиваем
        async with session.get(url) as response:
            return await response.json(){}
    

➡️ Так ты можешь совмещать CPU-работу (которая не блокирует) и IO-вызовы с лимитом. 🔍 Продвинутое использование: разные лимиты для разных эндпоинтов Допустим, у тебя два API: одно разрешает 5 RPS, другое - 10. Создай отдельные семафоры:

    
        
class RateLimiter:
    def __init__(self):
        self.sem_a = asyncio.Semaphore(5)
        self.sem_b = asyncio.Semaphore(10)

    async def call_api_a(self, session):
        async with self.sem_a:
            return await session.get('https://api.a.com/')

    async def call_api_b(self, session):
        async with self.sem_b:
            return await session.get('https://api.b.com/'){}
    

➡️ Изолированные лимиты для разных ресурсов. 🧪 Обработка таймаутов и повторных попыток В реальном коде нужно быть готовым к ошибкам. Комбинируем семафор с повторными попытками:

    
        
import async_timeout

async def fetch_with_retry(url, session, semaphore, retries=3):
    for attempt in range(retries):
        try:
            async with semaphore:
                async with async_timeout.timeout(5):  # таймаут 5 секунд
                    async with session.get(url) as response:
                        return await response.text()
        except (asyncio.TimeoutError, aiohttp.ClientError) as e:
            print(f'Попытка {attempt+1} для {url} не удалась: {e}')
            if attempt == retries - 1:
                raise
            await asyncio.sleep(2 ** attempt)  # экспоненциальная задержка{}
    

➡️ Если запрос провалился, пробуем снова, но не занимаем семафор во время паузы (пауза вне async with semaphore). 🚀 Практический кейс: вежливый парсер с ограничением Допустим, парсим сайт, который разрешает 2 запроса в секунду. Используем семафор + задержку между стартами:

    
        
async def crawl(urls):
    sem = asyncio.Semaphore(2)
    async with aiohttp.ClientSession() as session:
        tasks = []
        for url in urls:
            # запускаем корутину, но не ждем её сейчас
            task = asyncio.create_task(bounded_fetch(url, session, sem))
            tasks.append(task)
            # делаем паузу между стартами, чтобы не превысить лимит даже на старте
            await asyncio.sleep(0.5)  # 2 запроса в секунду -> пауза 0.5с
        results = await asyncio.gather(*tasks){}
    

➡️ Семафор ограничивает одновременные, а дополнительная пауза разносит старты. 🗣️ Запомни: Semaphore - это твой щит от троттлинга. Оборачивай каждый поход в сеть в async with semaphore и подбирай лимиты под API. Для разных эндпоинтов - разные семафоры. И никогда не забывай про таймауты. Полезен совет по защите от бана? Жмите 🔥

👩‍💻 Программирование — В С Ё В 2026 году на кодинге уже не вывезешь, перспектива года - Информационная Безопасность. Ловите полезные каналы, которые помогут ворваться в новое направление. 👍 ZeroDay — Уроки, эксплуатация уязвимостей с нуля 👍 Белый Хакер — Свежие новости из мира ИБ 😎 Бункер Хакера — Статьи, книги, шпаргалки и хакинг 👨‍💻 Серверная Админа — Настройка и уроки по компьютерным сетям 📂 Вступай и изучай новое направление!

🤐 Склеиваем списки с помощью `zip()` Частая задача: есть два связанных списка (например, имена и зарплаты), и нужно пройтись по ним одновременно. ⛔️ Плохой способ (через индекс):

    
        
names = ['Anna', 'Oleg']
salaries = [100, 200]

for i in range(len(names)):
    print(names[i], salaries[i])
{}
    

🖥 Pythonic способ: Функция zip берет по одному элементу из каждого списка и отдает их парами.

    
        
names = ['Anna', 'Oleg', 'Max']
salaries = [100, 200, 300]

for name, salary in zip(names, salaries):
    print(f"{name} получает {salary}k")
{}
    

💡 Важно: zip остановится, как только закончится самый короткий список. Если нужно сохранить все данные (заполнив пустоты None`), используйте `zip_longest из модуля itertools. #python #bestpractices #codingtips

Курсы прошел, а реально работающего сервиса так и не случилось? Код есть. Репозиторий тоже. А ссылки, которую можно кому-то скинуть - нет. Deploy-f закрывает это за 10 минут: - бот - API - Telegram mini app - всё с HTTPS и без зарубежных платежей В этом году Deploy-f снизил цены, чтобы джуны и соло-разработчики могли запускаться быстро, надежно и без лишних затрат. Проект без ссылки - это просто файл на ноутбуке 👉 Исправить это можно здесь

🛡 Pydantic + typing: валидация данных на этапе разработки с помощью assert_type Знаешь боль, когда Pydantic-модель прошла валидацию в рантайме, но mypy кричит на несоответствие типов? Решение есть — учим Pydantic и статические анализаторы понимать друг друга. ⚡️ Проблема: валидация есть, а типизации нет

    
        from pydantic import BaseModel, field_validator
from typing import assert_type

class User(BaseModel):
    id: int
    name: str
    
    @field_validator('id')
    @classmethod
    def validate_id(cls, v: str) -> int:  # Принимает str, возвращает int
        return int(v)

# Данные проходят валидацию
user = User.model_validate({"id": "123", "name": "Ivan"})
print(user.id)  # 123

# Но mypy не знает, что id точно int после валидации
assert_type(user.id, int)  # ✅ mypy теперь понимает{}
    

➡️ assert_type() не выполняет проверку в рантайме — это подсказка для mypy. Если типы не совпадут, анализатор ругнётся ещё до запуска. ✅ TypeGuard: кастомная валидация с информацией для mypy Когда стандартных валидаторов недостаточно, создаём функцию с TypeGuard:

    
        from typing import TypeGuard
from pydantic import BaseModel

class Item(BaseModel):
    value: str

def is_valid_item(data: dict) -> TypeGuard[Item]:
    """Проверяет, можно ли создать Item из data, и сообщает mypy о типе."""
    try:
        Item.model_validate(data)
        return True
    except:
        return False

# Пример использования
raw_data = {"value": "test"}

if is_valid_item(raw_data):
    # Здесь mypy точно знает, что raw_data подходит для Item
    item = Item.model_validate(raw_data)  # ✅ Без ошибок типизации
    print(item.value){}
    

➡️ TypeGuard — это явное обещание mypy: "Если функция вернула True, то тип такой-то". Работает в связке с isinstance. 🧪 Pydantic + typing.overload: точные типы для фабричных методов Когда метод может возвращать разные модели в зависимости от входных данных:

    
        from typing import overload, Union
from pydantic import BaseModel

class Success(BaseModel):
    data: dict
    status: str = "ok"

class Error(BaseModel):
    error: str
    status: str = "fail"

@overload
def create_response(data: dict) -> Success: ...

@overload
def create_response(data: None, error: str) -> Error: ...

def create_response(data: Union[dict, None] = None, error: str = "") -> Union[Success, Error]:
    if data is not None:
        return Success(data=data)
    return Error(error=error)

# Теперь mypy понимает, какая модель вернётся
result1 = create_response({"user": "Ivan"})
assert_type(result1, Success)  # ✅

result2 = create_response(error="Not found")
assert_type(result2, Error)  # ✅{}
    

➡️ @overload декларативно описывает все возможные сигнатуры функции. Mypy использует это для точного вывода типов. 🔍 ConfigDict(strict=True) + typing: полный контроль Заставляем Pydantic быть строгим, а mypy — проверять:

    
        from pydantic import BaseModel, ConfigDict
from typing import Literal

class StrictModel(BaseModel):
    model_config = ConfigDict(strict=True)
    
    id: int
    status: Literal["active", "pending"]  # Только два значения

# Эта строка вызовет ошибку валидации (строка вместо int)
# user = StrictModel.model_validate({"id": "100", "status": "active"})  # ❌ ValidationError

# А mypy поймает ошибку типа ещё раньше
from typing import TYPE_CHECKING

if TYPE_CHECKING:
    data: dict[str, str] = {"id": "100", "status": "active"}
    # mypy: error: Argument 1 to "model_validate" of "BaseModel" 
    # has incompatible type "dict[str, str]"; expected "dict[str, Any]"  ❌{}
    

➡️ Включаем strict=True в конфиге, чтобы Pydantic не пытался преобразовывать типы. Mypy увидит несоответствие в TYPE_CHECKING блоке. 🗣️ Запомни: assert_type и TypeGuard — это мосты между Pydantic и mypy. Первый говорит «поверь мне, здесь такой тип», второй — «я проверил данные и гарантирую тип». Используй их, чтобы ошибки типов ловились до запуска, а не в проде. Полезен совет по статической типизации? Жмите 🔥