NumPy 2.5.2 вышел 9 августа 2026 года и стал первой версией ветки 2.5 с готовыми wheel-сборками для Python 3.15.0rc1. Патч одновременно закрывает серию ошибок в StringDType, генераторах случайных чисел и низкоуровневом C API — часть из них могла приводить к повреждению данных или падению процесса.
NumPy 2.5.2 расширяет поддержку до Python 3.15
Самая заметная перемена в NumPy 2.5.2 связана с Python 3.15. Официальные release notes NumPy 2.5.2 прямо называют главным событием появление wheel-сборок для недавно выпущенного Python 3.15.0rc1. Поддерживаемый диапазон теперь указан как Python 3.12–3.15.
Здесь хорошо видна динамика ветки 2.5. NumPy 2.5.1, вышедший в июле, поддерживал Python 3.12–3.14 и содержал подготовительные изменения для следующей версии интерпретатора. Теперь эта подготовка перешла в практическую стадию: разработчики, которые тестируют проекты на Python 3.15.0rc1, получили готовые бинарные пакеты NumPy.
Python 3.15.0rc1 появился 4 августа 2026 года и открыл стадию release candidate. На этом этапе набор возможностей самого Python уже практически зафиксирован, а изменения до финального релиза в основном ограничиваются исправлениями ошибок. Для экосистемы научного Python такой момент особенно чувствителен: множество библиотек строится поверх NumPy, поэтому наличие готовой базовой зависимости позволяет раньше проверять совместимость всего стека.
Сам NumPy 2.5.2 остаётся патч-релизом. Новых крупных пользовательских API здесь нет. В центре выпуска — совместимость и исправления ошибок, найденных после NumPy 2.5.1.
StringDType получил исправления для ufunc и np.fromiter
Сразу несколько изменений затрагивают StringDType — тип строк переменной длины, который развивается в современной ветке NumPy.
Одна из ошибок находилась в механизме выбора параметра coerce для бинарных универсальных функций, или ufunc. При объединении двух StringDType NumPy по ошибке дважды проверял настройку первого операнда. В результате итог зависел от порядка аргументов: сочетание массива с coerce=True и массива с coerce=False могло вести себя по-разному после перестановки операндов.
В NumPy 2.5.2 логика исправлена: при определении результата учитываются оба дескриптора. Для кода, где строковые массивы участвуют в np.add и других бинарных операциях, это возвращает предсказуемое поведение независимо от порядка входных данных.
Более серьёзная ошибка обнаружилась в np.fromiter. Функция создаёт массив из итератора, например из генератора или последовательности, которую не хочется заранее превращать в список. При повторном использовании одного экземпляра StringDType прежняя реализация могла повторно задействовать входной дескриптор типа для записи результата.
Разработчики привели воспроизводимый пример с массивом из 20 000 строк: первый вызов np.fromiter завершался успешно, а повторный с тем же экземпляром StringDType приводил к Segmentation fault. Исправление разделяет входной дескриптор и структуру, используемую при создании выходного массива, поэтому повторное использование типа больше не должно повреждать внутреннее состояние.
В выпуск вошли и другие связанные правки: специальная обработка StringDType в np.isdtype, корректировка параметров coerce и na_object, а также удаление устаревших обходных решений при преобразовании строк в логические значения.
Генераторы случайных чисел защищены от гонок и старого состояния
Две правки затрагивают подсистему RNG — генераторы псевдослучайных чисел NumPy.
Первая закрывает гонку при обращении к внутреннему состоянию генератора. Аудит кода показал места, где состояние RNG читалось или изменялось без удержания соответствующей блокировки. В многопоточной программе два потока теоретически могли пересечься в таком участке и получить некорректную последовательность действий.
После исправления блокировка удерживается во всех проверенных местах доступа к состоянию. Разработчики отдельно воспроизвели гонку на тестовом сценарии и подтвердили, что после изменения она больше не возникает.
Вторая ошибка была связана с кэшированным состоянием генераторов, отличных от MT19937. При установке нового состояния часть служебного кэша могла сохранять значения от предыдущего состояния. В определённом сценарии следующий результат RNG формировался с участием старых данных.
Для статистических расчётов, моделирования и тестов воспроизводимость генератора имеет прямое значение. Если программа сохраняет состояние RNG, затем восстанавливает его и ожидает ту же последовательность, остаток внутреннего кэша нарушает эту модель. NumPy 2.5.2 полностью сбрасывает соответствующее кэшированное состояние.
C API для abi3t стал безопаснее на 32-битных системах
NumPy 2.5.2 меняет поведение PyArray_StringDTypeObject при использовании стабильного ABI, совместимого со свободнопоточным Python, — Py_TARGET_ABI3T.
В NumPy 2.5 структура PyArray_StringDTypeObject оказалась доступна расширениям целиком, хотя её внутреннее расположение полей зависит от размера заголовка Python-объекта. Авторы проекта указывают, что код, который обращался к этим полям в сборке abi3t, мог завершиться сбоем.
В 2.5.2 структура становится непрозрачной. Расширение получает указатель на объект, но не полагается на внутреннее расположение его полей. API аллокатора NpyString при этом остаётся доступен через указатель дескриптора.
Отдельная правка касается падений на 32-битных системах при работе с abi3t. Первый член PyArrayDescr теперь выравнивается по границе 8 байт, чтобы обращения к полям оставались корректными при различном размере реального PyObject. Авторы исправления специально сохранили совместимость с уже существующими abi3-расширениями, где размер объекта и раньше был кратен восьми.
Для авторов C- и Cython-расширений это один из наиболее технически значимых пунктов выпуска: NumPy продолжает адаптировать низкоуровневый интерфейс к свободнопоточной ветке Python и стабильным ABI, где ошибка в расположении структуры может проявляться как падение процесса далеко от исходного места проблемы.
Исправлены переполнения диагностических буферов и рекурсивный stack overflow
Ещё одна группа изменений работает глубже пользовательского Python-кода.
В функции проверки настроек CPU исправлены два выхода за границы диагностических буферов. Один сценарий возникал при максимально длинном значении переменной окружения и мог записать завершающий нулевой байт за пределы выделенного массива. Второй позволял повторяющимся именам неподдерживаемых CPU-функций переполнить буфер, предназначенный для диагностического сообщения.
Эти ошибки находились в коде, который разбирает переменные окружения с настройками процессорных возможностей во время импорта NumPy. Авторы PR отмечают, что в обычной сборке прежние выходы за границы памяти могли проходить без явного падения и лучше обнаруживались инструментами санитаризации памяти.
В arraydescr_dealloc устранён другой редкий сценарий. Освобождение базового дескриптора могло рекурсивно запускать новое освобождение arraydescr_dealloc. При специально сформированном dtype такая цепочка на новых версиях Python способна была закончиться переполнением стека. Исправление отсоединяет базовый объект перед операцией, которая может запустить его деалокацию, и разрывает рекурсивную последовательность.
Официальные материалы NumPy не связывают эти исправления с опубликованными CVE или отдельным security advisory. В release notes они проходят как обычные исправления ошибок.
В релиз вошли 28 PR с правками типов, индексации и управления памятью
В NumPy 2.5.2 объединено 28 pull request от 16 участников. Помимо наиболее заметных исправлений, выпуск включает несколько точечных изменений, которые закрывают редкие, но неприятные крайние случаи.
Среди них:
- устранена утечка счётчика ссылок при перекрывающемся
np.copytoсwhere=False; - восстановлен
ndarray.conjugate()для старых пользовательских dtype; - исправлена ситуация, когда ошибка преобразования могла теряться при присваивании через fancy indexing;
- исправлен шаг буферизованного итератора после удаления multi-index;
- устранена утечка ссылки в
simd_sequence_from_iterable; - добавлена защита от segfault, если у старого dtype отсутствует слот
copyswap; - обновлены аннотации типов, включая форму результата
np.iscloseдля двумерных array-like объектов; - обновлены компоненты сборки Meson, cibuildwheel и подмодуль x86-simd-sort.
Картина получается характерной для зрелого патч-релиза: изменения распределены между Python API, C API, типизацией, сборочной инфраструктурой и управлением памятью. Общая тема у них одна — устранение ситуаций, где редкое сочетание параметров, архитектуры или внутреннего состояния приводило к непредсказуемому результату.
NumPy 2.5.2 связывает ветку 2.5 с будущим Python 3.15
На 9 августа 2026 года точно известно, что NumPy 2.5.2 поддерживает Python 3.12–3.15 и включает wheel-сборки для Python 3.15.0rc1. Это завершает переход от подготовительных изменений в NumPy 2.5.1 к прямой поддержке текущего кандидата Python 3.15.
Внутри самого NumPy выпуск сосредоточен на корректности: StringDType больше не должен повреждать данные в описанном сценарии np.fromiter, состояние RNG защищено блокировками и полностью сбрасывает кэш, а несколько проблем C API и управления памятью закрыты до финального Python 3.15.
Вопрос о том, насколько экосистема вокруг NumPy совместима с Python 3.15, остаётся открытым. Хотя наличие базовых wheel-сборок устраняет один из первоначальных препятствий, реальная ситуация для SciPy, pandas, scikit-learn и других специализированных расширений станет ясна по мере проведения их собственных тестов и выпуска новых версий..
