Pandas 3.0 em 2026: novas APIs, mudanças incompatíveis e perguntas de entrevista

Pandas 3.0, lançado em 21 de janeiro de 2026, introduz as mudanças arquiteturais mais significativas desde a era 1.x da biblioteca. Copy-on-Write se torna o comportamento padrão, colunas de texto passam para um dtype baseado em PyArrow, e o novo construtor de expressões pd.col() oferece uma alternativa mais limpa às funções lambda. Essas mudanças afetam toda base de código existente e são cada vez mais cobradas em entrevistas de data engineering.

Copy-on-Write: o fim do SettingWithCopyWarning

Copy-on-Write (CoW) muda fundamentalmente a forma como o pandas gerencia a memória compartilhada entre DataFrames. Toda operação de indexação agora retorna o que se comporta como uma cópia, mas internamente o pandas compartilha a memória até que uma mutação realmente ocorra.

O impacto prático é imediato: SettingWithCopyWarning não existe mais. Padrões de atribuição encadeada como df[df['A'] > 0]['B'] = 1 agora lançam um ChainedAssignmentError porque o resultado intermediário da indexação é uma cópia.

# migration_cow.py
import pandas as pd

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

# Padrão Pandas 2.x (agora lança ChainedAssignmentError)
# df[df["category"] == "A"]["price"] = 150  # QUEBRADO no 3.0

# Padrão correto Pandas 3.0: usar .loc[]
df.loc[df["category"] == "A", "price"] = 150

# Compartilhamento de memória CoW em ação
df2 = df[["price"]]  # compartilha memória com df
df2["price"] = df2["price"] * 2  # cópia disparada apenas aqui
# df permanece inalterado - sem efeitos colaterais

O argumento copy presente em muitos métodos não tem mais efeito algum e pode ser removido com segurança do código existente. Métodos que suportam inplace=True (replace(), fillna(), ffill(), bfill(), clip()) agora retornam self em vez de None, permitindo o encadeamento de métodos mesmo com operações in-place.

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

Pandas 3.0 infere colunas de texto com um dtype str dedicado baseado em Apache Arrow, substituindo o antigo dtype object. Se o PyArrow não estiver instalado, o fallback utiliza arrays object do NumPy.

Os ganhos de desempenho são substanciais: .str.contains(), .str.lower() e outros métodos string executam de 5 a 10 vezes mais rápido. O consumo de memória para colunas de texto cai até 50%. O formato colunar Arrow também permite a troca de dados zero-copy com Polars, DuckDB e outras ferramentas nativas Arrow.

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

# Pandas 3.0: colunas string são automaticamente str[pyarrow]
df = pd.DataFrame({"name": ["Alice", "Bob", "Charlie", None]})
print(df.dtypes)
# name    string[pyarrow]
# dtype: object

# Valores ausentes usam NaN (não pd.NA), consistente com outros dtypes
print(df["name"].isna())  # True para a entrada None

# Interoperabilidade direta com DuckDB (zero-copy)
import duckdb
result = duckdb.sql("SELECT name FROM df WHERE name LIKE '%li%'").df()

Uma restrição importante: arrays PyArrow são imutáveis. Converter uma coluna baseada em PyArrow para um array NumPy gravável requer uma cópia explícita via .to_numpy(copy=True).

O construtor de expressões pd.col()

Pandas 3.0 introduz pd.col() como forma declarativa de referenciar colunas de um DataFrame e construir expressões. A sintaxe se inspira no PySpark e Polars, resolvendo problemas conhecidos com escopo de lambdas e sua opacidade.

# 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: baseado em lambdas (opaco, problemas de escopo)
df = df.assign(profit=lambda x: x["revenue"] - x["cost"])

# Depois: pd.col() (declarativo, introspectável)
df = df.assign(
    profit=pd.col("revenue") - pd.col("cost"),
    margin=((pd.col("revenue") - pd.col("cost")) / pd.col("revenue") * 100)
)

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

A vantagem principal sobre lambdas aparece em loops, onde closures lambda capturam variáveis por referência e produzem resultados incorretos:

# loop_scoping_fix.py
import pandas as pd

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

# Bug lambda: todas as colunas usam factor=30 (último valor do loop)
# cols = {}
# for factor in [2, 5, 10]:
#     cols[f"x{factor}"] = lambda x: x["base"] * factor  # BUG

# Correção pd.col(): cada expressão captura o valor correto
cols = {}
for factor in [2, 5, 10]:
    cols[f"x{factor}"] = pd.col("base") * factor  # Correto
df = df.assign(**cols)

Desde o pandas 3.0.2, pd.col() também funciona em Series.case_when(). Agregações groupby ainda não são suportadas.

Mudanças incompatíveis: checklist completo de migração

A tabela a seguir resume as mudanças incompatíveis com maior probabilidade de surgir durante a migração do pandas 2.x:

| Mudança | Comportamento pandas 2.x | Comportamento pandas 3.0 | Correção | |---------|--------------------------|--------------------------|----------| | Atribuição encadeada | SettingWithCopyWarning | ChainedAssignmentError | Usar .loc[] | | Dtype string | object | string[pyarrow] | Atualizar verificações de dtype | | Argumento copy= | Cria uma cópia | Sem efeito (deprecado) | Remover o argumento | | groupby(observed=) | Padrão False | Padrão True | Definir explicitamente | | Index.sort_values() | Args posicionais permitidos | Apenas args nomeados | Nomear todos os argumentos | | offsets.Day | Período fixo 24h | Dia calendário (DST-aware) | Revisar lógica de fuso horário | | Categorical.map(na_action=) | Padrão None | Default alterado | Definir explicitamente | | str.contains(na=) | Não-bool permitido | Apenas bool ou None | Limpar parâmetro na |

O caminho de atualização recomendado: primeiro atualizar para pandas 2.3, resolver todos os avisos de deprecação e então migrar para 3.0.

Nova política de deprecação: Pandas4Warning e Pandas5Warning

Pandas 3.0 introduz um ciclo de deprecação estruturado em 3 estágios. Funcionalidades primeiro emitem um DeprecationWarning padrão, depois mudam para um FutureWarning na última versão menor antes da próxima major, e finalmente são removidas na versão major.

Duas novas classes de aviso facilitam a filtragem por versão alvo:

# filter_warnings.py
import warnings
import pandas as pd

# Capturar apenas mudanças previstas para pandas 4.0
warnings.filterwarnings("error", category=pd.errors.Pandas4Warning)

# Capturar mudanças previstas para pandas 5.0
warnings.filterwarnings("default", category=pd.errors.Pandas5Warning)

Essa política concede aos mantenedores de bibliotecas pelo menos dois ciclos de versões menores para se adaptarem antes da chegada das mudanças incompatíveis.

Perguntas de entrevista: Pandas 3.0 em profundidade

Estas perguntas aparecem em entrevistas de data engineering e analytics em 2026, testando tanto a compreensão teórica quanto a experiência prática de migração.

P1: Explicar Copy-on-Write no pandas 3.0. Por que foi introduzido?

CoW garante que cada DataFrame ou Series retornado por uma operação de indexação se comporte como uma cópia independente. Internamente, o pandas compartilha a memória entre o original e o resultado até que um deles seja mutado, momento em que uma cópia física ocorre. Isso elimina a ambiguidade entre views e cópias que causava SettingWithCopyWarning, previne a corrupção acidental de dados por efeitos colaterais, e reduz o uso de memória para cargas de trabalho de leitura.

P2: O que acontece com df[condition]['col'] = value no pandas 3.0?

Lança ChainedAssignmentError. O df[condition] intermediário é agora sempre uma cópia (por causa do CoW), então atribuir a uma coluna dessa cópia não tem efeito no DataFrame original. O padrão correto é df.loc[condition, 'col'] = value.

P3: Como o novo dtype string afeta a interoperabilidade com outras ferramentas?

O dtype string baseado em PyArrow armazena dados no formato colunar Apache Arrow. Isso permite a transferência zero-copy para outras ferramentas nativas Arrow (Polars, DuckDB, Spark via PyArrow) sem sobrecarga de serialização. Também reduz a pegada de memória comparado com arrays object Python, já que Arrow usa buffers binários compactos em vez de objetos string Python individuais.

P4: Qual problema pd.col() resolve que lambdas não conseguem?

pd.col() captura as referências de colunas e valores no momento de criação da expressão, não no momento de execução. Lambdas em Python capturam variáveis por referência, o que causa bugs em loops onde todas as lambdas acabam referenciando o último valor da variável do loop. Além disso, expressões pd.col() são introspectáveis (pandas pode otimizá-las), enquanto lambdas são callables opacos.

P5: Como migrar uma base de código do pandas 2.x para 3.0?

Passo 1: Atualizar para pandas 2.3 e corrigir todos os avisos de deprecação. Passo 2: Ativar CoW em opt-in via pd.options.mode.copy_on_write = True (disponível desde 2.0) e corrigir os padrões de atribuição encadeada. Passo 3: Instalar PyArrow e testar que a inferência do dtype string não quebre a lógica downstream (especialmente verificações dtype == object). Passo 4: Atualizar para 3.0 e executar a suíte de testes completa. Passo 5: Remover argumentos copy= mortos e atualizar as chamadas groupby(observed=).

Benchmarks de desempenho: antes e depois

O efeito combinado de CoW e strings PyArrow entrega melhorias mensuráveis em cargas de trabalho reais:

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

# Gerar um DataFrame com 1M de linhas de dados mistos
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)
})

# Filtragem string: ~6x mais rápido com backend PyArrow
clicks = df.loc[pd.col("event").str.contains("click")]

# Memória: coluna string usa ~50% menos RAM
print(df["event"].memory_usage(deep=True))  # ~8MB vs ~16MB com dtype object

# Subsetting: CoW evita cópia até a mutação
subset = df[["user_id", "value"]]  # zero-copy (memória compartilhada)
subset["value"] = subset["value"].clip(upper=500)  # cópia disparada aqui apenas

Em pipelines ETL de produção processando CSVs com alto conteúdo textual, o backend string PyArrow sozinho reduz o pico de memória entre 30-40% e diminui o tempo total de execução entre 20-30% em transformações intensivas de strings.

Padrões de migração práticos: correções reais

Uma base de código pandas 2.x típica precisa destas refatorações específicas:

# migration_patterns.py
import pandas as pd

# Padrão 1: Substituir atribuição encadeada
# Antes (pandas 2.x)
# df[df["status"] == "active"]["score"] = 100
# Depois (pandas 3.0)
df.loc[df["status"] == "active", "score"] = 100

# Padrão 2: Remover argumentos copy=
# Antes
# subset = df[["a", "b"]].copy()  # desnecessário com CoW
# Depois
subset = df[["a", "b"]]  # CoW gerencia o isolamento automaticamente

# Padrão 3: Atualizar verificações de dtype para strings
# Antes
# if df["name"].dtype == object:
# Depois
if pd.api.types.is_string_dtype(df["name"]):
    pass

# Padrão 4: observed= explícito no groupby
# Antes (dependia do default observed=False)
# df.groupby("category")["value"].sum()
# Depois (explícito para clareza)
df.groupby("category", observed=True)["value"].sum()

# Padrão 5: Index.sort_values() apenas com argumentos nomeados
# Antes
# idx.sort_values(True, "first")
# Depois
idx.sort_values(ascending=True, na_position="first")

Para aprofundar as competências fundamentais em pandas e análise de dados Python, os módulos de perguntas de entrevista cobrem esses padrões em detalhe. O módulo de funções janela SQL complementa o conhecimento de pandas para vagas de analytics híbridos SQL/Python.

Conclusão

• Copy-on-Write elimina SettingWithCopyWarning por completo e previne a mutação acidental de dados através de referências compartilhadas
• O backend string PyArrow entrega operações string 5-10x mais rápidas e uma redução de memória de 50% para colunas de texto
• pd.col() substitui padrões lambda propensos a erros com expressões declarativas e introspectáveis
• A atribuição encadeada (df[cond]['col'] = val) é agora um erro definitivo que exige migração para .loc[]
• A política de deprecação estruturada (Pandas4Warning, Pandas5Warning) fornece cronogramas de atualização claros
• Caminho de atualização: primeiro pandas 2.3 (corrigir avisos), depois 3.0 (com PyArrow instalado e Python 3.11+)
• A preparação para entrevistas deve focar nos mecanismos CoW, interoperabilidade PyArrow e padrões de migração práticos