NumPy 2.x Migration Guide (2026)

NumPy 2.x Is the Biggest Overhaul in Almost Two Decades — Here's What Actually Matters

NumPy is the invisible foundation beneath virtually everything in the Python data science stack. Pandas, scikit-learn, matplotlib, SciPy, TensorFlow, PyTorch — they all lean on NumPy for their core array operations. So when the NumPy team shipped version 2.0.0 in June 2024 — the first major version bump since 2006 — it sent ripples through the entire Python scientific computing ecosystem.

And honestly? The ripples were justified.

Now, as of early 2026, we're at NumPy 2.4.1, and the dust has settled enough to take a clear-eyed look at everything that changed. The 2.x series brought breaking API changes, a fundamentally new type promotion system, variable-length string support, GPU-friendly array protocols, free-threaded Python compatibility, and performance improvements that make basic operations up to 15x faster in certain cases.

Whether you're still running NumPy 1.x in production (no judgment — we've all been there), recently upgraded and wondering what broke, or starting a fresh project and want to leverage NumPy's latest capabilities, this guide walks through the entire 2.0–2.4 journey with practical code examples, migration strategies, and real-world advice.

The NumPy 2.0 Breaking Changes That Actually Affect You

Let's start with the elephant in the room. NumPy 2.0 broke backward compatibility — both at the Python level and the C ABI level. This was intentional and necessary, but it meant that every package depending on NumPy's C API needed to rebuild. By now, the ecosystem has caught up, but understanding what changed is still crucial if you're migrating legacy code.

The Namespace Cleanup

NumPy 2.0 removed roughly 100 items from the main np namespace. If you're getting AttributeError after upgrading, this is almost certainly why.

Here are the most common ones you'll hit:

import numpy as np

# These aliases were REMOVED in NumPy 2.0:
# np.float_    → use np.float64
# np.complex_  → use np.complex128
# np.string_   → use np.bytes_
# np.unicode_  → use np.str_
# np.Inf       → use np.inf
# np.NaN       → use np.nan
# np.mat       → use np.asmatrix
# np.trapz     → use np.trapezoid
# np.in1d      → use np.isin

# Quick test: this raises AttributeError in NumPy 2.x
try:
    result = np.trapz([1, 2, 3])
except AttributeError:
    # Use the new name instead
    result = np.trapezoid([1, 2, 3])
    print(f"Trapezoidal integration: {result}")  # 4.0

The good news: there's an automated fixer. The NumPy team provides ruff rules that can scan and update your entire codebase in seconds:

# Install ruff if you don't have it
pip install ruff

# Fix NumPy 2.0 namespace changes across your project
ruff check --select NPY201 --fix .

# Preview what would change without modifying files
ruff check --select NPY201 .

I've run this on a few mid-sized codebases and it typically handles 90%+ of namespace-related issues. Run it, review the diff, and you're mostly done.

NEP 50: The Type Promotion Overhaul

This is the change that catches even experienced NumPy users off guard. Prior to 2.0, NumPy's type promotion rules were value-dependent — the result dtype could change depending on the actual values involved, not just their types. This led to inconsistent and frankly unpredictable behavior.

NumPy 2.0 implements NEP 50, which makes type promotion dtype-dependent only. The guiding principle is simple: values must never influence result types.

import numpy as np

# The classic example: float32 + Python float
a = np.float32(3.0)
b = 2.0  # Python float (float64)

result = a + b
print(result.dtype)
# NumPy 1.x: float64 (Python float "won")
# NumPy 2.x: float32 (Python scalars are "weakly" typed)

# NumPy scalar + NumPy scalar: the wider type wins
c = np.float32(3.0)
d = np.float64(2.0)
result = c + d
print(result.dtype)  # float64 — np.float64 is strictly typed

# This means mixed-precision operations may behave differently:
arr = np.arange(10, dtype=np.float32)
result = arr + 1.5  # Python float 1.5 adapts to float32
print(result.dtype)  # float32 (was float64 in NumPy 1.x!)

# If you need float64, be explicit:
result = arr + np.float64(1.5)
print(result.dtype)  # float64

The practical implication: if you were relying on Python scalars silently upcasting your arrays to float64, that no longer happens. You might see slightly different numerical results due to reduced precision. The fix is straightforward — use explicit NumPy dtypes when precision matters:

# Safe pattern for precision-sensitive code
import numpy as np

data = np.array([1.1, 2.2, 3.3], dtype=np.float32)

# Instead of: data + 0.1 (stays float32 in NumPy 2.x)
# Use explicit casting when you need float64 precision:
result = data.astype(np.float64) + 0.1
print(result.dtype)  # float64

This tripped me up on a production ML pipeline where we had float32 training data and were adding Python float constants everywhere. Subtle precision differences cascaded into noticeably different model outputs. Worth auditing carefully.

Integer Overflow Is Now an Error

Another behavioral change that affects real code: converting out-of-range values to integer scalars now raises OverflowError instead of silently wrapping:

import numpy as np

# NumPy 1.x: np.int8(256) silently wrapped to 0
# NumPy 2.x: raises OverflowError
try:
    val = np.int8(256)
except OverflowError as e:
    print(f"Caught: {e}")

# Array operations still wrap (unchanged behavior):
arr = np.array([256], dtype=np.int16)
result = arr.astype(np.int8)
print(result)  # [0] — still wraps in array context

This is honestly a good change — silent integer wrapping was a source of extremely subtle bugs.

Scalar Representation Changed

A small but noticeable change: NumPy scalars now display their type in their string representation:

import numpy as np

val = np.float64(3.14)
print(repr(val))   # np.float64(3.14)  — was just 3.14 in 1.x
print(str(val))    # 3.14  — str() still gives the clean value

# This matters for doctests, logging, and string formatting
# Use str() or f-strings for clean output:
print(f"The value is {val}")  # "The value is 3.14"

If you have doctests comparing scalar repr output, you'll need to update them. Not a big deal, but it can cause a surprising number of test failures on upgrade.

StringDType: Variable-Length UTF-8 Strings in NumPy

One of the most impactful additions in the NumPy 2.x series is StringDType — a proper, first-class string data type that stores variable-length UTF-8 strings. This has been a long-standing pain point for anyone working with text data in NumPy.

For years, if you wanted to store strings in a NumPy array, you had two bad options: fixed-width strings (wasteful padding, truncation risk) or object dtype (slow, no vectorization). StringDType fixes both problems.

Basic Usage

import numpy as np
from numpy.dtypes import StringDType

# Create a string array with variable-length strings
names = np.array(
    ["Alice", "Bob", "A much longer name that would waste space with fixed-width"],
    dtype=StringDType()
)

print(names.dtype)   # StringDType()
print(names[0])      # Alice
print(names[2])      # A much longer name that would waste space with fixed-width

# No padding, no truncation — each string uses exactly the memory it needs

Why StringDType Matters

The performance difference compared to object dtype is substantial. With object arrays, every string operation requires Python-level iteration — boxing and unboxing individual Python string objects. StringDType stores data in a compact binary format that enables true vectorized operations:

import numpy as np
from numpy.dtypes import StringDType

# Create a large string array
n = 100_000
emails = np.array(
    [f"user_{i}@example.com" for i in range(n)],
    dtype=StringDType()
)

# String operations via numpy.strings are vectorized
from numpy import strings

# These run at near-C speed, not Python-loop speed:
domains = strings.find(emails, "@")
upper = strings.upper(emails)
replaced = strings.replace(emails, "example", "company")

Missing Data Support

StringDType also supports configurable missing value handling — something object arrays only handled through convention (and a lot of None-checking):

import numpy as np
from numpy.dtypes import StringDType

# Enable missing data support with a custom sentinel
dt = StringDType(na_object=np.nan)
arr = np.array(["hello", None, "world"], dtype=dt)
print(arr)  # ['hello' nan 'world']

# You can also use pandas-compatible NA:
import pandas as pd
dt_pd = StringDType(na_object=pd.NA)
arr_pd = np.array(["hello", None, "world"], dtype=dt_pd)
print(arr_pd)  # ['hello'  'world']

Performance Comparison

NumPy 2.4 further improved StringDType performance. The np.unique function now uses a hash-based algorithm for string deduplication, yielding an order-of-magnitude speedup on large string arrays. Internal benchmarks showed roughly 1 billion string elements completing in 33.5 seconds, compared to 498 seconds with the sort-based method — a 15x improvement. That's not a typo.

import numpy as np
from numpy.dtypes import StringDType
import time

# Performance test: unique values on a large string array
n = 1_000_000
categories = np.random.choice(
    ["Electronics", "Books", "Clothing", "Home", "Sports",
     "Toys", "Food", "Health", "Auto", "Garden"],
    size=n
)

# Convert to StringDType
str_arr = np.array(categories, dtype=StringDType())

start = time.perf_counter()
unique_vals = np.unique(str_arr)
elapsed = time.perf_counter() - start
print(f"Unique on StringDType: {elapsed:.4f}s")
print(f"Found {len(unique_vals)} unique values")

The Array API Standard: NumPy's Bridge to GPUs

NumPy 2.x fully embraces the Python Array API standard — a cross-library specification that defines a common interface for array operations. If you've read about scikit-learn's GPU support, this is the same underlying standard making that possible. It's a foundational piece of the modern Python scientific computing ecosystem.

What the Array API Means in Practice

Code written against the standard interface can work with NumPy, CuPy (NVIDIA GPU), PyTorch, JAX, or any other compliant library without modification. That's the promise, and it actually delivers. NumPy 2.x includes Array API-compatible aliases and functions in the main namespace:

import numpy as np

# Array API standard functions available directly in NumPy 2.x
arr = np.array([[1, 2], [3, 4]], dtype=np.float64)

# Matrix transpose (Array API standard)
transposed = arr.mT              # Attribute form
transposed = np.matrix_transpose(arr)  # Function form

# New dtype classification
print(np.isdtype(arr.dtype, np.floating))   # True
print(np.isdtype(arr.dtype, np.integer))    # False

# Device support (CPU only in NumPy, but API is consistent)
print(arr.device)  # cpu

# New linalg functions following the standard
u, s, vh = np.linalg.svd(arr)
singular_values = np.linalg.svdvals(arr)  # New: singular values only
mat_norm = np.linalg.matrix_norm(arr)     # New: explicit matrix norm
vec_norm = np.linalg.vector_norm(s)       # New: explicit vector norm

Writing Library-Agnostic Code

If you're writing a library or utility functions, the Array API standard lets you support multiple backends from a single codebase. This is where things get really interesting:

import numpy as np

def normalize_features(X):
    """Normalize features to zero mean, unit variance.
    Works with NumPy, CuPy, PyTorch tensors, etc."""
    mean = X.mean(axis=0)
    std = X.std(axis=0)
    # Replace zero std to avoid division by zero
    std_safe = np.where(std == 0, 1.0, std)
    return (X - mean) / std_safe

# Works with regular NumPy arrays
data = np.random.randn(1000, 50).astype(np.float32)
normalized = normalize_features(data)
print(f"Mean: {normalized.mean(axis=0)[:3]}")  # Near zero
print(f"Std:  {normalized.std(axis=0)[:3]}")   # Near one

Performance Improvements Across the 2.x Series

Each release in the 2.x series brought meaningful performance improvements. Some of these are the kind of "boring but important" optimizations that collectively make everything feel snappier. Let's look at the highlights.

Scalar Operations: Up to 6x Faster

NumPy 2.4 dramatically improved the performance of operations on scalar values. Single-input ufuncs operating on scalars are now approximately 6x faster than in previous versions.

This matters more than you might think — scalar operations are surprisingly common in data validation, threshold checking, and scientific computations:

import numpy as np
import time

# Scalar operations — significantly faster in NumPy 2.4
val = np.float64(3.14)

start = time.perf_counter()
for _ in range(1_000_000):
    _ = np.sin(val)
    _ = np.exp(val)
    _ = np.sqrt(val)
elapsed = time.perf_counter() - start
print(f"1M scalar ufunc calls: {elapsed:.3f}s")

np.unique: Hash-Based Algorithm

The unique extraction algorithm was overhauled in NumPy 2.4 to use hash tables instead of sorting for complex, byte-string, unicode-string, and StringDType arrays. The speedups are dramatic:

Complex dtypes: 1.4–5x faster depending on the proportion of unique values
String dtypes: Up to 15x faster on large arrays
Few unique values: Even greater gains (5x+ when only 0.2% of values are unique)

import numpy as np

# Hash-based unique is particularly fast with low cardinality
data = np.random.choice(
    [1+2j, 3+4j, 5+6j, 7+8j, 9+10j],  # 5 unique complex values
    size=1_000_000
)

unique_vals, counts = np.unique(data, return_counts=True)
print(f"Unique complex values: {len(unique_vals)}")
for val, count in zip(unique_vals, counts):
    print(f"  {val}: {count:,} occurrences")

Important caveat: the hash-based method doesn't guarantee sorted output for strings and complex types. If you need sorted results, add an explicit sort step after np.unique.

np.ndindex: 5.2x Faster

The np.ndindex iterator was reimplemented using itertools.product under the hood, yielding a 5.2x speedup. This benefits code that iterates over multi-dimensional index spaces:

import numpy as np

# ndindex iteration — 5.2x faster in NumPy 2.4
arr = np.zeros((100, 100, 100))
for idx in np.ndindex(arr.shape):
    pass  # Iteration itself is much faster

# Practical use case: custom sliding window operations
def sliding_window_stats(arr, window_size=3):
    """Compute statistics over a sliding window."""
    pad = window_size // 2
    result = np.empty_like(arr, dtype=np.float64)
    for idx in np.ndindex(arr.shape):
        slices = tuple(
            slice(max(0, i - pad), min(s, i + pad + 1))
            for i, s in zip(idx, arr.shape)
        )
        result[idx] = arr[slices].mean()
    return result

Quantile Accuracy Improvements

NumPy 2.4 also improved the accuracy of np.quantile and np.percentile for 16-bit and 32-bit floating point arrays. Previously, intermediate calculations could lose precision; now the computations are handled more carefully:

import numpy as np

# More accurate quantile calculations for lower-precision dtypes
data = np.random.randn(10_000).astype(np.float16)

q25, q50, q75 = np.quantile(data, [0.25, 0.5, 0.75])
print(f"Q25: {q25:.4f}, Median: {q50:.4f}, Q75: {q75:.4f}")

# Weighted quantiles (introduced in NumPy 2.0)
weights = np.abs(data).astype(np.float16)
weighted_median = np.quantile(
    data, 0.5,
    weights=weights,
    method="inverted_cdf"
)
print(f"Weighted median: {weighted_median:.4f}")

Free-Threaded Python Support

One of the most forward-looking features of the NumPy 2.x series is its work toward supporting free-threaded Python — the no-GIL builds of CPython 3.13+ that allow true parallel execution of Python threads. NumPy is doing the foundational heavy lifting to make this a reality.

What Free Threading Means for NumPy

In traditional CPython, the Global Interpreter Lock (GIL) prevents multiple threads from executing Python bytecode simultaneously. NumPy has always released the GIL during long-running C-level operations (like large matrix multiplications), but many smaller operations were still serialized.

With free-threaded Python, all that changes. Multiple threads can execute NumPy operations truly in parallel — array creation, element-wise operations, reductions, the whole lot. NumPy 2.x has been systematically making internal data structures thread-safe to support this:

import numpy as np
from concurrent.futures import ThreadPoolExecutor

def process_chunk(chunk):
    """Process a data chunk — runs in parallel with free-threaded Python."""
    result = np.sqrt(np.abs(chunk))
    result = result[result > 0.5]
    return np.mean(result)

# Create a large dataset
data = np.random.randn(10_000_000)
chunks = np.array_split(data, 8)  # Split across 8 threads

# With free-threaded Python, this achieves true parallelism
with ThreadPoolExecutor(max_workers=8) as executor:
    results = list(executor.map(process_chunk, chunks))

print(f"Chunk means: {[f'{r:.4f}' for r in results]}")
print(f"Overall mean: {np.mean(results):.4f}")

Deprecations Supporting Thread Safety

NumPy 2.4 deprecated setting the strides attribute on arrays directly, because mutating shared array metadata is fundamentally unsafe in a multi-threaded context. Use np.lib.stride_tricks.as_strided() instead:

import numpy as np

arr = np.arange(12)

# DEPRECATED in NumPy 2.4:
# arr.strides = (16,)  # Direct mutation — thread-unsafe

# Use the safe alternative:
from numpy.lib.stride_tricks import as_strided
strided_view = as_strided(arr, shape=(6,), strides=(16,))
print(strided_view)  # [0 2 4 6 8 10]

Runtime Signature Introspection

Here's a quality-of-life improvement that doesn't get enough attention: over 300 NumPy functions now support inspect.signature(). This means your IDE's autocomplete and inline documentation actually work properly:

import numpy as np
import inspect

# In NumPy 1.x, this would raise ValueError for many functions
sig = inspect.signature(np.array)
print(sig)
# (object, dtype=None, *, copy=True, order='K', subok=False, ndmin=0, like=None)

# Works for ufuncs too:
sig = inspect.signature(np.add)
print(sig)

# And ndarray methods:
sig = inspect.signature(np.ndarray.reshape)
print(sig)

# Practical benefit: better IDE autocomplete, better documentation
# in Jupyter notebooks, and more accurate runtime type checking

This change is particularly valuable for Jupyter notebook users. Tab-completion and shift-tab documentation now show proper parameter names and defaults for the vast majority of NumPy's API. It's one of those things you don't realize you were missing until it works.

The New numpy.finfo: Reliable Machine Limits

NumPy 2.4 refactored how floating-point machine constants are determined. Previously, NumPy used a runtime discovery algorithm called MachAr that could occasionally produce incorrect results on unusual hardware. Now, constants are derived directly from C compiler macros (FLT_EPSILON, DBL_MIN, etc.), making them reliable across all platforms:

import numpy as np

# finfo now uses compiler-derived constants (NumPy 2.4)
f32_info = np.finfo(np.float32)
print(f"float32 epsilon: {f32_info.eps}")
print(f"float32 max:     {f32_info.max}")
print(f"float32 min:     {f32_info.tiny}")

f64_info = np.finfo(np.float64)
print(f"float64 epsilon: {f64_info.eps}")
print(f"float64 max:     {f64_info.max}")

# Useful for setting numerical tolerances
def safe_divide(a, b, dtype=np.float64):
    """Division with epsilon-based zero protection."""
    eps = np.finfo(dtype).eps
    return a / np.maximum(np.abs(b), eps) * np.sign(b)

Practical Migration Guide: From NumPy 1.x to 2.4

If you're still on NumPy 1.x and planning to upgrade, here's a step-by-step strategy that minimizes risk. I've used this approach on several projects and it works well.

Step 1: Check Your Dependencies

Before touching NumPy itself, verify that your other packages support NumPy 2.x. By early 2026, virtually all major packages do, but it's worth checking — especially if you have niche domain-specific libraries:

# Check which packages depend on NumPy
pip show numpy | grep -i required

# Check specific packages for NumPy 2 compatibility
pip install --dry-run 'numpy>=2.0' 2>&1 | head -20

# Key packages and their NumPy 2.x compatible versions:
# pandas >= 2.2.0
# scipy >= 1.14.0
# scikit-learn >= 1.5.0
# matplotlib >= 3.9.0
# statsmodels >= 0.14.2

Step 2: Run the Automated Fixer

# Install ruff and run the NumPy 2.0 migration rule
pip install ruff
ruff check --select NPY201 --fix .

# Review the changes
git diff

Step 3: Audit Type Promotion Sensitivity

Search your codebase for mixed-precision operations where Python scalars interact with NumPy arrays. These are the sneaky ones:

# Common patterns to audit:
# 1. Float32 arrays + Python float literals
data_f32 = np.array([1.0, 2.0], dtype=np.float32)
result = data_f32 + 0.5  # Now stays float32!

# 2. Integer overflow in scalar context
try:
    np.uint8(300)  # Now raises OverflowError
except OverflowError:
    val = np.uint16(300)  # Use a wider type

# 3. Operations that relied on value-dependent promotion
a = np.float32(1.0)
b = 2.0  # Python float
c = a + b  # Now float32, was float64 in NumPy 1.x

Step 4: Update String Handling

If you're using object dtype for string arrays, consider migrating to StringDType for better performance:

import numpy as np
from numpy.dtypes import StringDType

# Old approach:
old_strings = np.array(["hello", "world"], dtype=object)

# New approach — faster and more memory-efficient:
new_strings = np.array(["hello", "world"], dtype=StringDType())

# Convert existing object arrays:
converted = old_strings.astype(StringDType())

Step 5: Run Your Test Suite

After making these changes, run your full test suite with NumPy 2.x installed. Pay special attention to:

Numerical results that changed due to type promotion (NEP 50)
Tests that compare repr() output of NumPy scalars
Code that accesses private modules like np.core or np.linalg.linalg
Operations that mix NumPy arrays with plain Python scalars

# Run tests with verbose output to catch warnings
python -W all -m pytest tests/ -v

# If you use doctest, update expected output for scalar repr:
# Old: >>> np.float64(3.14)
#      3.14
# New: >>> np.float64(3.14)
#      np.float64(3.14)

Expired Deprecations: What Was Finally Removed in 2.4

NumPy 2.4 cleaned up a significant number of long-deprecated features. If you skipped intermediate versions, some of these removals might surprise you:

import numpy as np

# np.in1d — removed, use np.isin
# Old: np.in1d([1, 2, 3], [2, 3])
# New:
result = np.isin([1, 2, 3], [2, 3])
print(result)  # [False  True  True]

# interpolation parameter in quantile — use method=
# Old: np.quantile(data, 0.5, interpolation='linear')
# New:
data = np.array([1.0, 2.0, 3.0, 4.0, 5.0])
q = np.quantile(data, 0.5, method='linear')
print(q)  # 3.0

# np.trapz — removed, use np.trapezoid
# Old: np.trapz([1, 2, 3])
# New:
area = np.trapezoid([1, 2, 3])
print(area)  # 4.0

# Direct generator to np.sum — use np.fromiter
# Old: np.sum(x**2 for x in range(10))
# New:
total = np.sum(np.fromiter((x**2 for x in range(10)), dtype=float))
print(total)  # 285.0

# ndindex.ndincr() — use next()
idx = np.ndindex(3, 3)
first = next(idx)  # Instead of idx.ndincr()
print(first)  # (0, 0)

New Utility Features Worth Knowing About

The ndmax Parameter for np.array

NumPy 2.4 added an ndmax parameter to np.array that limits how many dimensions are created from nested sequences. This is surprisingly useful when you want to create arrays of lists without full unpacking:

import numpy as np

# Without ndmax — creates a 2D array
data = [[1, 2], [3, 4], [5, 6]]
arr_2d = np.array(data, dtype=object)
print(arr_2d.shape)  # (3, 2)

# With ndmax=1 — creates a 1D array of lists
arr_1d = np.array(data, dtype=object, ndmax=1)
print(arr_1d.shape)  # (3,)
print(arr_1d[0])     # [1, 2] — preserved as a list

Enhanced np.pad with Dictionary pad_width

import numpy as np

# Pad a 2D array with different widths per axis using a dictionary
arr = np.ones((3, 4))
padded = np.pad(arr, pad_width={0: (1, 2), 1: (0, 3)}, constant_values=0)
print(padded.shape)  # (6, 7) — 1 top + 3 original + 2 bottom, 4 original + 3 right

The same_value Casting Mode

NumPy 2.4 introduced a new casting='same_value' option that checks whether values can survive a round-trip cast without changing. This is invaluable for data validation:

import numpy as np

# Validate that float data can be safely converted to int
data = np.array([1.0, 2.0, 3.0])
int_data = data.astype(np.int64, casting='same_value')  # Works — all values are whole numbers
print(int_data)  # [1 2 3]

# This will raise ValueError because 1.5 can't round-trip:
try:
    bad_data = np.array([1.0, 1.5, 2.0])
    bad_data.astype(np.int64, casting='same_value')
except ValueError as e:
    print(f"Caught: {e}")  # Values would change during cast

What's Coming Next: The Road to NumPy 2.5

As of early 2026, the NumPy development branch shows continued work on several fronts:

Deeper free-threaded Python support: More internal structures being made thread-safe for CPython 3.14+
User DType API stabilization: The __numpy_dtype__ protocol introduced in 2.4 is being refined, enabling downstream libraries to create custom dtypes more easily
StringDType improvements: Continued performance optimizations and broader function support
Array API alignment: Closing remaining gaps with the evolving Array API standard

The trajectory is clear: NumPy is evolving from a pure CPU, single-threaded, NumPy-only world into a flexible foundation that supports multiple backends, true parallelism, and modern Python type safety. The 2.x series has already delivered on much of that vision, and the pace of improvement shows no signs of slowing down.

Wrapping Up

NumPy 2.x represents the most significant evolution of Python's numerical foundation in nearly two decades. The breaking changes in 2.0 were substantial but necessary — cleaning up the namespace, making type promotion predictable, and laying the groundwork for GPU computing and free-threaded Python. The subsequent releases through 2.4 have delivered on the performance promises with concrete speedups in scalar operations, string handling, and unique extraction.

If you haven't migrated yet, now is the time. The ecosystem has caught up, the migration tools are mature, and the performance and safety benefits are real. Run ruff check --select NPY201 --fix on your codebase, audit your type promotion assumptions, consider adopting StringDType for string-heavy workflows, and enjoy a faster, more predictable NumPy.

The upgrade isn't painless, but it's worth it. And with the migration tooling available today, it's a lot less painful than it would have been even a year ago.