Что бы ты хотел добавить в Python?

Что я хотел бы добавить в Python

Этот вопрос о моём видении эволюции языка. Я выбрал бы несколько фич, которые решают реальные проблемы, с которыми я сталкиваюсь в работе.

1. Встроенная валидация типов с runtime проверками

Проблема: типизация сейчас работает только для статического анализа (mypy). В runtime типы игнорируются.

# Сейчас (типы — только для анализа)
def process(data: list[str]) -> int:
    return len(data)

result = process([1, 2, 3])  # Ошибка в runtime? Нет!
print(result)  # 3 — типизация не помогла

# Хотел бы видеть (type guards в runtime)
@runtime_typed
def process(data: list[str]) -> int:
    # Автоматическая проверка перед вызовом
    return len(data)

result = process([1, 2, 3])  # TypeError: Expected list[str], got list[int]

Почему это полезно:

• Ловлю баги на границах API
• Самопроверка в production
• Не нужно писать валидаторы Pydantic в каждом проекте
• Документация через код

2. Pattern matching с полноценными guards

Проблема: match-case работает, но guards слишком ограничены.

# Сейчас
match request:
    case {"type": "login", "user": str(user), "pass": str(password)}:
        if len(password) >= 8:  # Дополнительная проверка
            authenticate(user, password)
    case _:
        raise ValueError("Invalid request")

# Хотел бы (встроенный синтаксис для guards)
match request:
    case {
        "type": "login",
        "user": str(user),
        "pass": str(password) where len(password) >= 8
    }:
        authenticate(user, password)
    case _:
        raise ValueError("Invalid request")

Почему полезно:

• Более читаемый код
• Меньше вложенности
• Guards как первоклассный гражданин

3. Встроенный async yield (async generator improvements)

Проблема: async генераторы работают, но много подводных камней.

# Сейчас (работает, но требует внимательности)
async def fetch_users(api):
    for user_id in range(1, 101):
        user = await api.get_user(user_id)
        yield user  # Требует async for

# Использование
async for user in fetch_users(api):
    print(user)

# Хотел бы (auto-batching generators)
async def fetch_users(api):
    async for page in api.paginate_users():
        yield from page  # Или yield from с await

# Или встроенные batch-операции
async def process_in_batches(generator, batch_size=100):
    async for batch in generator.batch(batch_size):
        await process(batch)

4. Встроенная оптимизация памяти для больших структур

Проблема: в Python на 64-битной системе целое число занимает ~28 байт.

# Сейчас
ints = [1, 2, 3, 4, 5]  # Каждое число ~28 байт = 140 байт

# Хотел бы видеть (auto-packing)
compact_ints = [1, 2, 3, 4, 5] @ compact  # или специальный синтаксис
# 5 целых чисел = 40 байт (как в numpy)

# Или встроенные структуры данных
from collections import CompactArray
compact_array = CompactArray[int]([1, 2, 3, 4, 5])

5. Встроенный параллелизм без GIL (уже в плане!)

Проблема: GIL ломает многопоточность.

# Сейчас (многопоточность работает только для I/O)
from concurrent.futures import ThreadPoolExecutor

def cpu_bound_task(n):
    return sum(i**2 for i in range(n))

with ThreadPoolExecutor(max_workers=4) as executor:
    results = list(executor.map(cpu_bound_task, [10**7]*4))
# Медленно из-за GIL!

# Хотел бы видеть (встроенный parallelism)
import parallel

@parallel.task
def cpu_bound_task(n):
    return sum(i**2 for i in range(n))

results = [cpu_bound_task(10**7) for _ in range(4)]  # Параллельно

Хорошие новости: Python 3.13+ уже работает над удалением GIL!

6. Синтаксический сахар для иммутабельных структур

Проблема: создание неизменяемых объектов слишком многословно.

# Сейчас
from dataclasses import dataclass
from typing import Frozen

@dataclass(frozen=True)
class Point:
    x: float
    y: float

# Хотел бы видеть (встроенный синтаксис)
immutable class Point:
    x: float
    y: float

# Или
record Point:
    x: float
    y: float

Почему полезно:

• Меньше кода
• Явное намерение (immutable)
• Автоматические eq, hash, repr

7. Встроенная трассировка ошибок (уже частично есть!)

Проблема: при ошибке в глубоком стеке вызовов сложно понять контекст.

# Хотел бы видеть (улучшенный traceback по умолчанию)
try:
    result = complex_calculation()
except ValueError as e:
    # Автоматически показывает:
    # - Значение переменных в каждом фрейме
    # - Форму переданных объектов
    # - Цепочку вызовов
    traceback.print_detailed()

Хорошие новости: Python 3.11+ улучшил error messages!

Что я НЕ добавлял бы

Не нужны:

• Встроенный модуль для Machine Learning (numpy, torch решают это)
• Встроенный web framework (Django, FastAPI лучше)
• Полностью новый синтаксис (Python красив своей простотой)
• Null-safety как в TypeScript (Optional[T] достаточно)

Мой идеальный Python будущего

# Все вместе
import parallel
from typing import TypeGuard, Final

@parallel.task
@runtime_typed
immutable class Result:
    value: int
    timestamp: Final[str]

async def process_data(data: list[int]) -> Result:
    match data:
        case [x, y, *rest] where x + y > 0:
            computed = await compute_parallel(rest)
            return Result(value=computed, timestamp=now())
        case _:
            raise ValueError("Invalid data")

async def compute_parallel(items):
    async for batch in async_batch(items, size=100):
        results = await parallel.map(expensive_calc, batch)
        yield from results

Почему именно эти улучшения

1. Безопасность — типы и валидация спасают от ошибок
2. Производительность — параллелизм и оптимизация памяти
3. Читаемость — pattern matching и синтаксический сахар
4. Практичность — решают реальные боли в production
5. Совместимость — не ломают существующий код

Вывод

Лучший язык программирования — это баланс между мощью (типизация, параллелизм) и простотой (читаемость, few ways to do it). Python близко подошёл к этому, и я просто хотел бы закончить работу над runtime типами и параллелизмом без GIL — это решит 90% моих проблем в production.