🖥 Python не медленный. Медленным его часто делает ваш код.

У Python есть странная репутация: стоит программе начать тормозить, виноват сразу язык. Но в реальности большая часть быстрых сценариев в Python работает не потому, что интерпретатор внезапно стал магическим, а потому что тяжёлая работа уходит ниже - в C, C++ или Rust.

CPython написан на C. Многие встроенные операции тоже выполняются в C:

- len()
- list.append()
- dict.get()
- sum()
- сортировка
- операции со строками
- часть работы со списками и словарями

Когда вы вызываете list.append(), Python не крутит всю логику добавления элемента на уровне байткода. Он платит небольшой overhead за вызов, а дальше попадает в C-функцию внутри CPython.

Медленный путь начинается там, где мы вручную гоняем данные по одному элементу:


total = 0

for x in data:
total += x


На каждой итерации интерпретатор должен выполнить байткод, достать объект, проверить типы, сделать операцию, обновить значение и перейти к следующему элементу. Для маленьких списков это незаметно. Для миллионов элементов это уже цена, которую вы платите за каждую итерацию.

Быстрый путь выглядит иначе:


total = sum(data)


Здесь цикл проталкивается внутрь реализации. Python остаётся удобной оболочкой, а основная работа выполняется ближе к нативному коду.

С NumPy та же идея, только ещё жёстче:


total = np.sum(data)


Внутренний цикл почти не возвращается в Python. Массив обрабатывается внутри оптимизированного нативного кода, а обратно приходит уже готовый результат.

Поэтому фраза «Python медленный» слишком грубая.

Точнее так:

Python-циклы дорогие
C-циклы дешёвые
built-in функции часто быстрее ручного кода
NumPy быстрый не из-за синтаксиса, а потому что не гоняет каждый элемент через интерпретатор
хороший Python-код старается как можно дольше оставаться внутри готовых операций и библиотек

Оптимизация Python часто начинается не с переписывания проекта на Go или Rust, а с простого вопроса:

можно ли убрать ручной цикл и отдать работу тому коду, который уже написан на C, C++ или Rust?

Python хорош не как самый быстрый исполнитель каждой операции.

Он хорош как удобный слой управления над быстрыми нативными кусками.

@Python_Community_ru