Hola! Gracias por la librería.
El problema
A partir del 4.º trimestre de 2024, el rediseño del cuestionario de la EPH
eliminó de las bases usuarias varias variables agregadas, que fueron
"atomizadas" en sub-componentes por fuente:
- Base hogar (estrategias del hogar, sí/no):
V5, V11, V21, V22
→ reemplazadas por V5_01–V5_03, V11_01–V11_02, V21_01–V21_03,
V22_01–V22_03.
- Base individual (montos de ingresos no laborales):
V2_M, V5_M,
V11_M, V21_M, V22_M → reemplazadas por sus sub-componentes *_0X_M.
Además, en las bases publicadas las columnas PP11L1 y PP11L2 aparecen
con los contenidos intercambiados.
Hoy pyeph.get(data="eph", ...) descarga estas bases tal cual, por lo que
cualquier serie que use esas variables (ingresos no laborales, estrategias
de los hogares) se corta en 2024-T3 sin aviso.
La propuesta
Una función nueva en pyeph/tools/ — nombre tentativo
comparability_bridge() (alias puente_comparabilidad, siguiendo la
convención de la librería) — que reconstruye las variables eliminadas con
reglas determinísticas y corrige la inversión PP11L1/PP11L2:
import pyeph
hogares = pyeph.get(data="eph", year=2025, period=1, base_type="hogar")
individuos = pyeph.get(data="eph", year=2025, period=1, base_type="individual")
hogares = pyeph.comparability_bridge(hogares)
individuos = pyeph.comparability_bridge(individuos, base_hogar=hogares)
Las reglas de reconstrucción están documentadas y validadas:
- Tessmer, G. & Boggiano, B. (2026). From Breaks to Bridges: Harmonizing
the New and Old Permanent Household Survey for Consistent Labor Market
Series (SSRN Working Paper 6597399).
- Manual Metodológico EPH – Observatorio (UNR), Parte A
(https://hdl.handle.net/2133/33253). Es la lógica del pipeline
EPH-Observatorio, en producción desde 2024-T4
(datasets en https://doi.org/10.57715/UNR/BL85Z8).
Ya propusimos la misma funcionalidad al paquete eph de R, que ustedes
citan en el README (ropensci/eph#70),
con la idea de mantener simetría entre los dos ecosistemas.
La función ya está escrita en el estilo de la librería (pandas, logging,
alias en castellano, sin dependencias nuevas), con tests pytest que no
requieren red, y la verificamos contra la implementación R de referencia
con un chequeo de equivalencia exhaustivo (580 combinaciones de códigos +
comparación de punta a punta sobre bases sintéticas, resultado idéntico).
Funciona con pandas 2.x y 3.x. Si les parece bien la idea, mandamos el PR.
Dos consultas:
- ¿Les cierra
comparability_bridge / puente_comparabilidad como nombre,
y pyeph/tools/ como ubicación (la pensamos análoga a merge/aparear)?
- ¿Ven razonable integrarla más adelante al flujo de
get() (p. ej. un
argumento opcional), o mejor mantenerla como paso explícito?
Saludos,
Germán Tessmer (Observatorio Económico Social, UNR —
https://germantessmer.github.io/) y Bárbara Boggiano (Universidad Alberto
Hurtado — https://sites.google.com/view/barbaraboggiano/home)
Hola! Gracias por la librería.
El problema
A partir del 4.º trimestre de 2024, el rediseño del cuestionario de la EPH
eliminó de las bases usuarias varias variables agregadas, que fueron
"atomizadas" en sub-componentes por fuente:
V5,V11,V21,V22→ reemplazadas por
V5_01–V5_03,V11_01–V11_02,V21_01–V21_03,V22_01–V22_03.V2_M,V5_M,V11_M,V21_M,V22_M→ reemplazadas por sus sub-componentes*_0X_M.Además, en las bases publicadas las columnas
PP11L1yPP11L2aparecencon los contenidos intercambiados.
Hoy
pyeph.get(data="eph", ...)descarga estas bases tal cual, por lo quecualquier serie que use esas variables (ingresos no laborales, estrategias
de los hogares) se corta en 2024-T3 sin aviso.
La propuesta
Una función nueva en
pyeph/tools/— nombre tentativocomparability_bridge()(aliaspuente_comparabilidad, siguiendo laconvención de la librería) — que reconstruye las variables eliminadas con
reglas determinísticas y corrige la inversión
PP11L1/PP11L2:Las reglas de reconstrucción están documentadas y validadas:
the New and Old Permanent Household Survey for Consistent Labor Market
Series (SSRN Working Paper 6597399).
(https://hdl.handle.net/2133/33253). Es la lógica del pipeline
EPH-Observatorio, en producción desde 2024-T4
(datasets en https://doi.org/10.57715/UNR/BL85Z8).
Ya propusimos la misma funcionalidad al paquete
ephde R, que ustedescitan en el README (ropensci/eph#70),
con la idea de mantener simetría entre los dos ecosistemas.
La función ya está escrita en el estilo de la librería (pandas, logging,
alias en castellano, sin dependencias nuevas), con tests pytest que no
requieren red, y la verificamos contra la implementación R de referencia
con un chequeo de equivalencia exhaustivo (580 combinaciones de códigos +
comparación de punta a punta sobre bases sintéticas, resultado idéntico).
Funciona con pandas 2.x y 3.x. Si les parece bien la idea, mandamos el PR.
Dos consultas:
comparability_bridge/puente_comparabilidadcomo nombre,y
pyeph/tools/como ubicación (la pensamos análoga amerge/aparear)?get()(p. ej. unargumento opcional), o mejor mantenerla como paso explícito?
Saludos,
Germán Tessmer (Observatorio Económico Social, UNR —
https://germantessmer.github.io/) y Bárbara Boggiano (Universidad Alberto
Hurtado — https://sites.google.com/view/barbaraboggiano/home)