Как относишься к тайпингу?

Отношение к типизации в Python

Типизация (typing) — одна из ключевых практик современной разработки на Python. Мое отношение к ней более чем позитивное, и вот почему.

1. Преимущества типизации

1.1 Раннее обнаружение ошибок

Типизация позволяет статическим анализаторам (mypy, pyright) найти ошибки до запуска кода:

# БЕЗ типизации — ошибка видна только в runtime
def add(a, b):
    return a + b

result = add(5, "10")  # Ошибка в runtime: TypeError

# С типизацией — ошибка видна сразу в IDE
def add(a: int, b: int) -> int:
    return a + b

result = add(5, "10")  # mypy: Argument 2 has incompatible type "str"

Экономия времени: ловим ошибки на этапе разработки, а не в production.

1.2 Улучшенная читаемость и документация

Типы — это встроенная документация кода:

# Без типов: что возвращает эта функция?
def process_user(data):
    return data.get("name") or "Unknown"

# С типами: сразу понятна сигнатура
from typing import Dict, Optional

def process_user(data: Dict[str, str]) -> str:
    return data.get("name") or "Unknown"

# IDE автоматически подсказывает методы и атрибуты
result: str = process_user({"name": "John"})

1.3 Поддержка IDE (autocomplete)

Целые IDE оптимизированы для типизированного кода:

from dataclasses import dataclass

@dataclass
class User:
    id: int
    name: str
    email: str

def get_user(user_id: int) -> User:
    return User(id=user_id, name="John", email="john@example.com")

# IDE знает все атрибуты User и подсказывает их
user = get_user(1)
print(user.name)  # IDE подсказывает: name, id, email
print(user.nonexistent)  # IDE предупреждает об ошибке

1.4 Рефакторинг без страха

При изменении типов IDE поможет найти все места, требующие обновления:

# Было
def create_user(name: str, email: str) -> int:
    # ...
    return user_id

# Меняю: теперь возвращаю объект User вместо int
def create_user(name: str, email: str) -> User:
    # ...
    return User(id=1, name=name, email=email)

# IDE найдёт все места, где ожидается int,
# и предложит обновить
user_id: int = create_user("John", "john@example.com")  # Ошибка!

2. Типизация в разных контекстах

2.1 Функции

from typing import List, Dict, Tuple, Callable, Optional, Union

# Простые типы
def greet(name: str) -> str:
    return f"Hello, {name}"

# Коллекции
def process_numbers(numbers: List[int]) -> Dict[str, int]:
    return {"sum": sum(numbers), "count": len(numbers)}

# Кортежи
def get_coordinates() -> Tuple[int, int]:
    return (10, 20)

# Опциональные параметры
def find_user(user_id: int, include_deleted: bool = False) -> Optional[dict]:
    if user_id < 0:
        return None
    return {"id": user_id}

# Union типы (несколько вариантов)
def convert_to_int(value: Union[str, int]) -> int:
    if isinstance(value, int):
        return value
    return int(value)

# Callable (функции как аргументы)
def apply_operation(a: int, b: int, op: Callable[[int, int], int]) -> int:
    return op(a, b)

result = apply_operation(5, 3, lambda x, y: x + y)

2.2 Классы

from dataclasses import dataclass
from typing import ClassVar, List

@dataclass
class User:
    id: int
    name: str
    email: str
    tags: List[str] = None
    
    # Переменная уровня класса
    total_users: ClassVar[int] = 0
    
    def get_domain(self) -> str:
        return self.email.split("@")[1]
    
    @classmethod
    def from_dict(cls, data: dict) -> "User":
        return cls(**data)

# Использование
user = User(id=1, name="John", email="john@example.com")
domain = user.get_domain()  # IDE знает, что вернётся str

2.3 Дженерики (Generic types)

from typing import TypeVar, Generic, List

T = TypeVar("T")  # Параметр типа

class Stack(Generic[T]):
    def __init__(self) -> None:
        self.items: List[T] = []
    
    def push(self, item: T) -> None:
        self.items.append(item)
    
    def pop(self) -> T:
        return self.items.pop()

# Использование
int_stack: Stack[int] = Stack()
int_stack.push(5)
int_stack.push("hello")  # Ошибка: ожидается int

str_stack: Stack[str] = Stack()
str_stack.push("hello")
value = str_stack.pop()  # IDE знает, что это str

3. Строгая типизация в production

Для серьёзных проектов используй strict mode в mypy:

# mypy.ini или pyproject.toml
[mypy]
python_version = 3.10
warn_return_any = True
warn_unused_configs = True
disallow_untyped_defs = True      # Все функции должны иметь типы
disallow_incomplete_defs = True    # Нельзя Any в результатах
disallow_untyped_calls = True      # Вызывать только типизированные функции
strict = True                      # Максимальная строгость

# Со strict=True это неправильно:
def process(data):  # Ошибка: нет типов параметра
    return data.get("name")  # Ошибка: неизвестно, что вернётся

# Правильно:
def process(data: Dict[str, str]) -> Optional[str]:
    return data.get("name")

4. Protocol и Structural Typing

from typing import Protocol

# Определить контракт без наследования
class Drawable(Protocol):
    def draw(self) -> None:
        ...

class Circle:
    def draw(self) -> None:
        print("Drawing circle")

class Square:
    def draw(self) -> None:
        print("Drawing square")

def render(drawable: Drawable) -> None:
    drawable.draw()

# Обе работают, хотя не наследуют Drawable
render(Circle())   # OK
render(Square())   # OK

# Но это не работает:
class InvalidShape:
    pass

render(InvalidShape())  # Ошибка: не реализует Drawable

5. Type guards и narrowing

from typing import Union, TypeGuard

def is_string(value: Union[str, int]) -> TypeGuard[str]:
    return isinstance(value, str)

def process(value: Union[str, int]) -> None:
    if is_string(value):
        # IDE знает, что это str
        print(value.upper())
    else:
        # IDE знает, что это int
        print(value + 1)

6. Недостатки типизации

6.1 Дополнительный код

# Больше кода для написания
def add(a: int, b: int) -> int:
    return a + b

# vs
def add(a, b):
    return a + b

Решение: начни с документирования критических функций, потом постепенно типизируй весь код.

6.2 Бойлерплейт в больших проектах

# Много типов нужно для API
from typing import Optional, List
from pydantic import BaseModel

class UserCreate(BaseModel):
    name: str
    email: str
    age: Optional[int] = None

class User(UserCreate):
    id: int
    is_active: bool

# Много типов, но это дело привычки

Решение: используй Pydantic для автоматизации валидации и сериализации.

6.3 Runtime overhead минимален

import timeit

# БЕЗ типов
code1 = """
def add(a, b):
    return a + b
add(1, 2)
"""

# С типами
code2 = """
def add(a: int, b: int) -> int:
    return a + b
add(1, 2)
"""

time1 = timeit.timeit(code1, number=1000000)
time2 = timeit.timeit(code2, number=1000000)

print(f"Без типов: {time1:.4f}s")
print(f"С типами: {time2:.4f}s")
# Разница <1%! Типы — это только для статического анализа

7. Best practices

# 1. Типизируй public API
public_function(data: Dict[str, Any]) -> Optional[User]:
    pass

# 2. Используй type hints для параметров и возвращаемых значений
def process(x: int, y: int) -> int:
    return x + y

# 3. Не используй Any без необходимости
# Плохо
def func(data: Any) -> Any:
    pass

# Хорошо
from typing import TypeVar
T = TypeVar("T")
def func(data: T) -> T:
    pass

# 4. Используй Literal для перечисления значений
from typing import Literal

def set_status(status: Literal["active", "inactive", "pending"]) -> None:
    pass

# 5. Документируй сложные типы
def process(
    users: List[Dict[str, Union[str, int]]]  # List of user dicts
) -> Dict[int, str]:  # Map of user_id to name
    pass

Мое резюме

Я ПОЛНОСТЬЮ за типизацию, потому что:

1. Экономит время → меньше багов на production
2. Улучшает читаемость → код становится самодокументируемым
3. Помогает рефакторингу → IDE предупредит об ошибках
4. Почти не влияет на production → это compile-time проверка
5. Стандарт индустрии → все крупные проекты используют typing

Для новых проектов я использую strict=True в mypy с самого начала.

Для legacy кода я постепенно добавляю типы, начиная с public API и критических функций.

Минимум: аннотируй параметры и возвращаемые значения функций. Это не требует много времени, но спасает часов отладки.