Pandas 3.0 en 2026: nuevas API, cambios incompatibles y preguntas de entrevista

Pandas 3.0, lanzado el 21 de enero de 2026, introduce los cambios arquitectónicos más significativos desde la era 1.x de la biblioteca. Copy-on-Write se convierte en el comportamiento por defecto, las columnas de texto pasan a un dtype respaldado por PyArrow, y el nuevo constructor de expresiones pd.col() ofrece una alternativa más limpia a las funciones lambda. Estos cambios afectan a toda base de código existente y son cada vez más evaluados en entrevistas de data engineering.

Copy-on-Write: el fin del SettingWithCopyWarning

Copy-on-Write (CoW) cambia fundamentalmente la forma en que pandas gestiona la memoria compartida entre DataFrames. Cada operación de indexación ahora retorna lo que se comporta como una copia, pero pandas internamente comparte la memoria hasta que ocurre una mutación real.

El impacto práctico es inmediato: SettingWithCopyWarning ya no existe. Los patrones de asignación encadenada como df[df['A'] > 0]['B'] = 1 ahora lanzan un ChainedAssignmentError porque el resultado intermedio de la indexación es una copia.

# migration_cow.py
import pandas as pd

df = pd.DataFrame({"price": [100, 200, 300], "category": ["A", "B", "A"]})

# Patrón Pandas 2.x (ahora lanza ChainedAssignmentError)
# df[df["category"] == "A"]["price"] = 150  # ROTO en 3.0

# Patrón correcto Pandas 3.0: usar .loc[]
df.loc[df["category"] == "A", "price"] = 150

# Memoria compartida CoW en acción
df2 = df[["price"]]  # comparte memoria con df
df2["price"] = df2["price"] * 2  # copia activada solo aquí
# df permanece sin cambios - sin efectos secundarios

El argumento copy presente en muchos métodos ya no tiene ningún efecto y puede eliminarse de forma segura del código existente. Los métodos que soportan inplace=True (replace(), fillna(), ffill(), bfill(), clip()) ahora retornan self en lugar de None, permitiendo el encadenamiento de métodos incluso con operaciones in-place.

Backend PyArrow para strings: 5-10x más rápido

Pandas 3.0 infiere las columnas de texto con un dtype str dedicado respaldado por Apache Arrow, reemplazando el antiguo dtype object. Si PyArrow no está instalado, el fallback utiliza arrays object de NumPy.

Las ganancias de rendimiento son sustanciales: .str.contains(), .str.lower() y otros métodos string se ejecutan 5 a 10 veces más rápido. El consumo de memoria para columnas de texto se reduce hasta un 50%. El formato columnar Arrow también permite el intercambio de datos zero-copy con Polars, DuckDB y otras herramientas nativas Arrow.

# string_dtype_comparison.py
import pandas as pd
import numpy as np

# Pandas 3.0: las columnas string son automáticamente str[pyarrow]
df = pd.DataFrame({"name": ["Alice", "Bob", "Charlie", None]})
print(df.dtypes)
# name    string[pyarrow]
# dtype: object

# Los valores faltantes usan NaN (no pd.NA), consistente con otros dtypes
print(df["name"].isna())  # True para la entrada None

# Interoperabilidad directa con DuckDB (zero-copy)
import duckdb
result = duckdb.sql("SELECT name FROM df WHERE name LIKE '%li%'").df()

Una restricción importante: los arrays PyArrow son inmutables. Convertir una columna respaldada por PyArrow a un array NumPy escribible requiere una copia explícita mediante .to_numpy(copy=True).

El constructor de expresiones pd.col()

Pandas 3.0 introduce pd.col() como una forma declarativa de referenciar columnas de un DataFrame y construir expresiones. La sintaxis se inspira en PySpark y Polars, resolviendo problemas conocidos con el alcance de las lambdas y su opacidad.

# col_expressions.py
import pandas as pd

df = pd.DataFrame({
    "revenue": [1000, 2500, 800, 3200],
    "cost": [400, 1200, 600, 1500],
    "region": ["US", "EU", "US", "APAC"]
})

# Antes: basado en lambdas (opaco, problemas de alcance)
df = df.assign(profit=lambda x: x["revenue"] - x["cost"])

# Después: pd.col() (declarativo, introspectable)
df = df.assign(
    profit=pd.col("revenue") - pd.col("cost"),
    margin=((pd.col("revenue") - pd.col("cost")) / pd.col("revenue") * 100)
)

# Filtrado con pd.col()
high_margin = df.loc[pd.col("margin") > 50]

La ventaja principal sobre las lambdas aparece en los bucles, donde los closures lambda capturan variables por referencia y producen resultados incorrectos:

# loop_scoping_fix.py
import pandas as pd

df = pd.DataFrame({"base": [10, 20, 30]})

# Bug lambda: todas las columnas usan factor=30 (último valor del bucle)
# cols = {}
# for factor in [2, 5, 10]:
#     cols[f"x{factor}"] = lambda x: x["base"] * factor  # BUG

# Corrección pd.col(): cada expresión captura el valor correcto
cols = {}
for factor in [2, 5, 10]:
    cols[f"x{factor}"] = pd.col("base") * factor  # Correcto
df = df.assign(**cols)

Desde pandas 3.0.2, pd.col() también funciona en Series.case_when(). Las agregaciones groupby aún no están soportadas.

Cambios incompatibles: checklist completo de migración

La siguiente tabla resume los cambios incompatibles con mayor probabilidad de aparecer durante la migración desde pandas 2.x:

| Cambio | Comportamiento pandas 2.x | Comportamiento pandas 3.0 | Solución | |--------|---------------------------|---------------------------|----------| | Asignación encadenada | SettingWithCopyWarning | ChainedAssignmentError | Usar .loc[] | | Dtype string | object | string[pyarrow] | Actualizar verificaciones de dtype | | Argumento copy= | Crea una copia | Sin efecto (deprecado) | Eliminar el argumento | | groupby(observed=) | Por defecto False | Por defecto True | Establecer explícitamente | | Index.sort_values() | Args posicionales permitidos | Solo args con nombre | Nombrar todos los argumentos | | offsets.Day | Período fijo 24h | Día calendario (DST-aware) | Revisar lógica de zona horaria | | Categorical.map(na_action=) | Por defecto None | Cambio de default | Establecer explícitamente | | str.contains(na=) | No-bool permitido | Solo bool o None | Limpiar parámetro na |

La ruta de actualización recomendada: primero actualizar a pandas 2.3, resolver todas las advertencias de deprecación y luego pasar a 3.0.

Nueva política de deprecación: Pandas4Warning y Pandas5Warning

Pandas 3.0 introduce un ciclo de deprecación estructurado en 3 etapas. Las funcionalidades primero emiten un DeprecationWarning estándar, luego cambian a un FutureWarning en la última versión menor antes de la próxima mayor, y finalmente se eliminan en la versión mayor.

Dos nuevas clases de advertencia facilitan el filtrado por versión objetivo:

# filter_warnings.py
import warnings
import pandas as pd

# Capturar solo cambios previstos para pandas 4.0
warnings.filterwarnings("error", category=pd.errors.Pandas4Warning)

# Capturar cambios previstos para pandas 5.0
warnings.filterwarnings("default", category=pd.errors.Pandas5Warning)

Esta política otorga a los mantenedores de bibliotecas al menos dos ciclos de versiones menores para adaptarse antes de que lleguen los cambios incompatibles.

Preguntas de entrevista: Pandas 3.0 en profundidad

Estas preguntas aparecen en entrevistas de data engineering y analytics en 2026, evaluando tanto la comprensión teórica como la experiencia práctica de migración.

P1: Explicar Copy-on-Write en pandas 3.0. ¿Por qué se introdujo?

CoW garantiza que cada DataFrame o Series retornado por una operación de indexación se comporte como una copia independiente. Internamente, pandas comparte la memoria entre el original y el resultado hasta que uno de ellos es mutado, momento en el cual ocurre una copia física. Esto elimina la ambigüedad entre vistas y copias que causaba SettingWithCopyWarning, previene la corrupción accidental de datos por efectos secundarios, y reduce el uso de memoria para cargas de trabajo de lectura.

P2: ¿Qué sucede con df[condition]['col'] = value en pandas 3.0?

Lanza ChainedAssignmentError. El df[condition] intermedio es ahora siempre una copia (gracias a CoW), por lo que asignar a una columna de esa copia no tiene efecto en el DataFrame original. El patrón correcto es df.loc[condition, 'col'] = value.

P3: ¿Cómo afecta el nuevo dtype string a la interoperabilidad con otras herramientas?

El dtype string respaldado por PyArrow almacena datos en formato columnar Apache Arrow. Esto permite la transferencia zero-copy hacia otras herramientas nativas Arrow (Polars, DuckDB, Spark vía PyArrow) sin sobrecarga de serialización. También reduce la huella de memoria comparado con arrays object de Python, ya que Arrow usa buffers binarios compactos en lugar de objetos string Python individuales.

P4: ¿Qué problema resuelve pd.col() que las lambdas no pueden resolver?

pd.col() captura las referencias de columnas y valores en el momento de creación de la expresión, no en el momento de ejecución. Las lambdas en Python capturan variables por referencia, lo que causa bugs en bucles donde todas las lambdas terminan referenciando el último valor de la variable del bucle. Además, las expresiones pd.col() son introspectables (pandas puede optimizarlas), mientras que las lambdas son callables opacos.

P5: ¿Cómo migrar una base de código de pandas 2.x a 3.0?

Paso 1: Actualizar a pandas 2.3 y corregir todas las advertencias de deprecación. Paso 2: Activar CoW en opt-in mediante pd.options.mode.copy_on_write = True (disponible desde 2.0) y corregir los patrones de asignación encadenada. Paso 3: Instalar PyArrow y verificar que la inferencia del dtype string no rompa la lógica downstream (especialmente las verificaciones dtype == object). Paso 4: Actualizar a 3.0 y ejecutar la suite de tests completa. Paso 5: Eliminar argumentos copy= muertos y actualizar las llamadas groupby(observed=).

Benchmarks de rendimiento: antes y después

El efecto combinado de CoW y strings PyArrow entrega mejoras medibles en cargas de trabajo reales:

# benchmark_example.py
import pandas as pd
import numpy as np

# Generar un DataFrame con 1M de filas de datos mixtos
rng = np.random.default_rng(42)
df = pd.DataFrame({
    "user_id": rng.integers(0, 100_000, size=1_000_000),
    "event": rng.choice(["click", "view", "purchase", "scroll"], size=1_000_000),
    "value": rng.exponential(50, size=1_000_000)
})

# Filtrado string: ~6x más rápido con backend PyArrow
clicks = df.loc[pd.col("event").str.contains("click")]

# Memoria: la columna string usa ~50% menos RAM
print(df["event"].memory_usage(deep=True))  # ~8MB vs ~16MB con dtype object

# Subsetting: CoW evita copiar hasta la mutación
subset = df[["user_id", "value"]]  # zero-copy (memoria compartida)
subset["value"] = subset["value"].clip(upper=500)  # copia activada aquí únicamente

En pipelines ETL de producción que procesan CSVs con alto contenido textual, el backend string PyArrow por sí solo reduce el pico de memoria entre 30-40% y disminuye el tiempo total de ejecución entre 20-30% en transformaciones intensivas de strings.

Patrones de migración prácticos: correcciones reales

Una base de código pandas 2.x típica necesita estas refactorizaciones específicas:

# migration_patterns.py
import pandas as pd

# Patrón 1: Reemplazar asignación encadenada
# Antes (pandas 2.x)
# df[df["status"] == "active"]["score"] = 100
# Después (pandas 3.0)
df.loc[df["status"] == "active", "score"] = 100

# Patrón 2: Eliminar argumentos copy=
# Antes
# subset = df[["a", "b"]].copy()  # innecesario con CoW
# Después
subset = df[["a", "b"]]  # CoW gestiona el aislamiento automáticamente

# Patrón 3: Actualizar verificaciones de dtype para strings
# Antes
# if df["name"].dtype == object:
# Después
if pd.api.types.is_string_dtype(df["name"]):
    pass

# Patrón 4: observed= explícito en groupby
# Antes (dependía del default observed=False)
# df.groupby("category")["value"].sum()
# Después (explícito para claridad)
df.groupby("category", observed=True)["value"].sum()

# Patrón 5: Index.sort_values() solo con argumentos nombrados
# Antes
# idx.sort_values(True, "first")
# Después
idx.sort_values(ascending=True, na_position="first")

Para profundizar en las competencias fundamentales de pandas y análisis de datos con Python, los módulos de preguntas de entrevista cubren estos patrones en detalle. El módulo de funciones ventana SQL complementa el conocimiento de pandas para roles de analytics híbridos SQL/Python.

Conclusión

• Copy-on-Write elimina SettingWithCopyWarning por completo y previene la mutación accidental de datos a través de referencias compartidas
• El backend string PyArrow entrega operaciones string 5-10x más rápidas y una reducción de memoria del 50% para columnas de texto
• pd.col() reemplaza patrones lambda propensos a errores con expresiones declarativas e introspectables
• La asignación encadenada (df[cond]['col'] = val) es ahora un error duro que requiere migración a .loc[]
• La política de deprecación estructurada (Pandas4Warning, Pandas5Warning) proporciona cronogramas de actualización claros
• Ruta de actualización: primero pandas 2.3 (corregir advertencias), luego 3.0 (con PyArrow instalado y Python 3.11+)
• La preparación para entrevistas debe enfocarse en los mecanismos CoW, interoperabilidad PyArrow y patrones de migración prácticos