Módulo 6: Programas robustos, modulares y documentados

Un programa puede producir el resultado correcto y aun así ser difícil de mantener:

un solo archivo de 500 líneas
        +
capturas que esconden cualquier error
        +
opciones escritas directamente en el código
        +
decenas de print() de diagnóstico
        ↓
programa frágil y difícil de reutilizar

En este módulo transformarás soluciones aisladas en programas pequeños que otra persona pueda ejecutar, comprender, corregir y reutilizar.

Aprenderás a:

• distinguir errores que deben corregirse de situaciones que pueden manejarse;
• capturar únicamente las excepciones que realmente comprendes;
• comunicar reglas incumplidas mediante raise;
• distribuir responsabilidades entre módulos;
• impedir que el programa se ejecute accidentalmente al importarlo;
• crear una interfaz de terminal con ayuda automática;
• separar los mensajes para el usuario del registro técnico;
• utilizar la documentación como herramienta diaria.

Principio del módulo: robustez no significa ocultar los errores; significa anticipar los casos esperables, comunicarlos y conservar visibles los fallos inesperados.

Al completar el módulo serás capaz de:

• Diferenciar errores de programación, datos inválidos y situaciones recuperables.
• Limitar un bloque try a la operación que puede fallar.
• Capturar excepciones específicas y utilizar múltiples manejadores.
• Aplicar else y finally con una intención clara.
• Lanzar excepciones integradas mediante raise.
• Crear una excepción personalizada sencilla cuando el dominio la justifique.
• Encadenar un error de bajo nivel con un error significativo para la aplicación.
• Crear módulos propios y reutilizar funciones sin copiar y pegar.
• Comprender espacios de nombres, alias y colisiones.
• Evitar importaciones con * y efectos secundarios al importar.
• Aplicar el patrón if __name__ == "__main__":.
• Separar entrada, lógica, presentación y configuración.
• Crear argumentos posicionales y opcionales con argparse.
• Configurar tipos, valores predeterminados, opciones y mensajes de ayuda.
• Diferenciar la salida dirigida al usuario de un registro técnico.
• Elegir entre DEBUG, INFO, WARNING, ERROR y CRITICAL.
• Registrar contexto útil sin exponer información sensible.
• Explorar objetos mediante help(), dir() y .__doc__.
• Leer firma, retorno, excepciones y disponibilidad por versión.
• Aplicar principios esenciales de PEP 8 y PEP 257.

Necesitas poder:

• crear funciones y utilizar parámetros;
• importar módulos de la biblioteca estándar;
• trabajar con cadenas, colecciones, fechas y números;
• leer y escribir archivos con Path;
• comprender clases básicas para declarar una excepción personalizada;
• ejecutar un archivo .py desde la terminal.

No se profundizará en paquetes distribuibles, pruebas automatizadas avanzadas, arquitectura empresarial ni publicación en PyPI. Esos temas pertenecen a una etapa posterior de Desarrollo de Software con Python.

Desarrollarás COA Toolkit, una caja de herramientas de terminal con tres operaciones:

texto    → normaliza y resume texto
fecha    → calcula y clasifica un vencimiento
números  → produce estadísticas descriptivas

La aplicación tendrá:

• argumentos y ayuda mediante argparse;
• módulos con responsabilidades distintas;
• excepciones específicas y mensajes comprensibles;
• registro de eventos mediante logging;
• salida opcional a un archivo sin sobrescribirlo;
• docstrings e instrucciones de ejecución;
• un punto de entrada que no se activa al importar.

Esta estructura preparará el terreno para el Proyecto Final Integrador, sin resolverlo de antemano.

Los retos opcionales requieren tiempo adicional.

Diseño de errores y excepciones

Capturar una excepción no arregla automáticamente su causa. Antes de escribir except, responde:

1. ¿Qué operación puede fallar?
2. ¿Qué excepciones concretas produce?
3. ¿Puede el programa continuar correctamente?
4. ¿Qué necesita saber el usuario?
5. ¿Qué contexto técnico debe registrarse?

try:
    numero = int(texto)
except ValueError:
    print("El valor debe ser un número entero.")
else:
    print(f"Conversión correcta: {numero}")
finally:
    print("Intento finalizado.")

try      → contiene la operación que puede fallar
except   → responde a un tipo de fallo conocido
else     → se ejecuta si el try terminó sin excepción
finally  → se ejecuta siempre al abandonar la estructura

No es obligatorio utilizar las cuatro partes. Agrega cada una únicamente cuando cumple una función real.

Versión problemática:

try:
    numero = int(texto)
    resultado = procesar(numero)
    guardar(resultado)
    mostrar(resultado)
except ValueError:
    print("Dato inválido.")

El ValueError podría provenir de la conversión, de procesar() o incluso de guardar(). El mensaje asume una causa sin saber cuál fue.

Versión más precisa:

try:
    numero = int(texto)
except ValueError:
    print("El valor recibido no es un entero.")
else:
    resultado = procesar(numero)
    guardar(resultado)
    mostrar(resultado)

El bloque protegido contiene únicamente la conversión que sabes manejar.

from pathlib import Path


def leer_configuracion(ruta):
    try:
        return Path(ruta).read_text(encoding="utf-8")
    except FileNotFoundError:
        print("No se encontró la configuración.")
    except PermissionError:
        print("No hay permiso para leer la configuración.")
    except UnicodeDecodeError:
        print("La configuración no utiliza UTF-8 válido.")

Cada excepción comunica una causa diferente y puede requerir una respuesta diferente.

Evita:

try:
    contenido = realizar_proceso()
except:
    pass

Una captura desnuda también intercepta señales como KeyboardInterrupt y oculta por completo el fallo.

Capturar Exception puede ser apropiado en el límite superior de una aplicación para registrar un fallo inesperado y terminar de forma controlada. No debe utilizarse para fingir que todo salió bien.

Coloca primero los tipos específicos:

try:
    ejecutar_operacion()
except FileNotFoundError as error:
    print(f"Archivo ausente: {error.filename}")
except OSError as error:
    print(f"Error del sistema de archivos: {error}")

FileNotFoundError es una subclase de OSError. Si OSError aparece primero, también capturará el archivo ausente y el manejador específico nunca se ejecutará.

try:
    cantidad = int(texto)
except ValueError:
    print("Cantidad inválida.")
else:
    total = calcular_total(cantidad)
    print(total)

El código del else no queda cubierto por el except. Si calcular_total() contiene un error inesperado, será visible en lugar de etiquetarse erróneamente como una conversión inválida.

def ejecutar_sesion(recurso):
    recurso.abrir()

    try:
        recurso.procesar()
    finally:
        recurso.cerrar()

finally se ejecuta aunque exista una excepción o un return. Es útil para liberar recursos cuando no existe un administrador de contexto apropiado.

Para archivos, prefiere with:

with ruta.open("r", encoding="utf-8") as archivo:
    contenido = archivo.read()

Evita devolver un valor desde finally: puede ocultar una excepción o reemplazar otro retorno, haciendo el flujo difícil de comprender.

Una función no siempre debe imprimir un mensaje o devolver None. Puede comunicar que su contrato fue incumplido:

def calcular_promedio(valores):
    if not valores:
        raise ValueError("Se necesita al menos un valor.")

    return sum(valores) / len(valores)

Quien llama decide cómo responder:

try:
    promedio = calcular_promedio([])
except ValueError as error:
    print(f"No se pudo calcular: {error}")

Utiliza tipos integrados cuando expresan bien la causa:

• ValueError: el tipo es aceptable, pero el valor no;
• TypeError: el tipo recibido no es compatible;
• FileNotFoundError: falta un archivo requerido;
• FileExistsError: una salida protegida ya existe.

Una excepción propia merece existir cuando permite expresar y capturar un problema del dominio que no queda claro mediante un tipo integrado.

class MuestraInsuficienteError(Exception):
    """Indica que la población no permite crear la muestra solicitada."""


def validar_muestra(poblacion, cantidad):
    if cantidad > len(poblacion):
        raise MuestraInsuficienteError(
            f"Se solicitaron {cantidad} elementos, pero solo existen {len(poblacion)}."
        )

No crees una excepción distinta para cada mensaje. Hazlo cuando el llamador necesite distinguir esa categoría de problema.

Los nombres de excepciones suelen terminar en Error.

Puedes traducir un error técnico a uno significativo sin perder la causa original:

from datetime import date


class FechaInvalidaError(ValueError):
    """Indica que una fecha no cumple el contrato de la aplicación."""


def convertir_fecha(texto):
    try:
        return date.fromisoformat(texto)
    except ValueError as error:
        raise FechaInvalidaError(
            f"La fecha debe usar AAAA-MM-DD: {texto!r}."
        ) from error

raise ... from error preserva la relación entre la causa original y la explicación del dominio.

Si cada capa captura, registra y vuelve a lanzar el mismo error, el archivo de registro se llena de copias.

Una estrategia simple:

• la función de lógica lanza una excepción clara;
• el punto de entrada la captura;
• el punto de entrada muestra un mensaje breve al usuario;
• el punto de entrada registra el contexto técnico una sola vez.

Módulos, importaciones y espacios de nombres

Archivo calculos.py:

def promedio(valores):
    if not valores:
        raise ValueError("No hay valores.")

    return sum(valores) / len(valores)

Archivo main.py:

import calculos


resultado = calculos.promedio([4, 6, 8])
print(resultado)

El prefijo calculos. comunica el origen de la función y evita colisiones.

import statistics

resultado = statistics.mean([2, 4, 6])

from statistics import mean

resultado = mean([2, 4, 6])

import statistics as stats

resultado = stats.mean([2, 4, 6])

Elige según claridad:

• import modulo hace visible el origen;
• from modulo import nombre es claro para unos pocos nombres inequívocos;
• as debe crear un alias conocido o realmente legible, no una abreviatura misteriosa.

from modulo_a import *
from modulo_b import *

Ahora no es evidente qué módulo definió cada nombre ni cuál reemplazó a otro. Utiliza importaciones explícitas.

Un espacio de nombres relaciona nombres con objetos. Dos módulos pueden definir validar() sin colisionar si se importan como módulos:

import fechas
import numeros


fechas.validar("2026-08-15")
numeros.validar("25.4")

Nombra módulos según su responsabilidad. Evita nombres que coincidan con la biblioteca estándar, como random.py, logging.py, json.py o statistics.py, porque pueden impedir que importes los módulos reales.

Archivo problemático:

print("Iniciando programa...")
respuesta = input("Escribe un valor: ")


def procesar(valor):
    return valor.strip()

Al ejecutar import modulo, Python ejecutará el print() y solicitará la entrada. Un módulo reutilizable no debería iniciar la interfaz, escribir archivos ni configurar globalmente el registro al importarse.

Conserva en el nivel superior únicamente declaraciones necesarias:

• constantes;
• funciones;
• clases;
• importaciones;
• configuraciones que no produzcan efectos externos innecesarios.

Una estructura simple puede fluir así:

main.py
  ├─ importa cli.py
  ├─ importa operaciones.py
  ├─ importa reportes.py
  └─ importa configuracion.py

operaciones.py
  └─ importa errores.py

Evita que operaciones.py importe main.py mientras main.py importa operaciones.py. Las importaciones circulares suelen revelar responsabilidades mezcladas.

Punto de entrada, estructura y documentación

Cuando ejecutas un archivo directamente:

python main.py

su variable __name__ vale "__main__".

Cuando lo importas:

import main

main.__name__ vale "main".

Por eso se utiliza:

def main():
    print("Aplicación iniciada.")


if __name__ == "__main__":
    main()

Importar el archivo define main(), pero no la ejecuta.

Una aplicación de terminal puede comunicar éxito o error al sistema operativo:

def main():
    try:
        ejecutar()
    except ValueError as error:
        print(f"Error: {error}")
        return 2

    return 0


if __name__ == "__main__":
    raise SystemExit(main())

Convención habitual:

• 0: finalización correcta;
• distinto de 0: ocurrió un problema.

No necesitas diseñar una tabla compleja de códigos. Sí debes distinguir éxito de fallo.

cli.py            → define y analiza argumentos
operaciones.py    → transforma y calcula
reportes.py       → presenta y guarda resultados
configuracion.py  → configura logging
errores.py        → declara errores del dominio
main.py           → coordina el flujo

Una función de lógica no debería llamar a input() ni decidir el color de un mensaje. Debe recibir datos y devolver un resultado o lanzar una excepción clara.

def clasificar_vencimiento(fecha_limite, referencia):
    """Clasifica una fecha como vencida, próxima o vigente.

    Args:
        fecha_limite: Fecha que se desea evaluar.
        referencia: Fecha desde la cual se calcula la diferencia.

    Returns:
        Un diccionario con la diferencia en días y la clasificación.

    Raises:
        TypeError: Si los argumentos no son objetos date.
    """

Una docstring describe el contrato. No necesita narrar línea por línea lo que el código ya muestra.

• Utiliza cuatro espacios por nivel de indentación.
• Escribe nombres de funciones y variables en snake_case.
• Utiliza MAYUSCULAS para constantes.
• Separa las importaciones de la biblioteca estándar de las importaciones propias.
• Mantén líneas y expresiones legibles.
• Deja dos líneas en blanco entre funciones de nivel superior.
• Elige nombres orientados a la intención.
• Evita comentarios que repitan literalmente el código.
• Escribe docstrings para módulos, funciones públicas, clases y excepciones relevantes.

PEP 8 y PEP 257 son guías para mejorar la comunicación, no una razón para sacrificar la claridad del problema.

Interfaz de terminal con argparse

Una interfaz con input() exige interacción manual. Los argumentos de terminal permiten:

• repetir una ejecución;
• documentar ejemplos exactos;
• combinar la herramienta con otros procesos;
• validar opciones de forma consistente;
• generar ayuda automáticamente.

python main.py fecha 2026-08-22 --referencia 2026-08-15

import argparse


def crear_parser():
    parser = argparse.ArgumentParser(
        description="Procesa una operación de COA Toolkit."
    )
    parser.add_argument("operacion", choices=["texto", "fecha", "numeros"])
    parser.add_argument("valores", nargs="+")
    return parser

parser = crear_parser()
argumentos = parser.parse_args()

print(argumentos.operacion)
print(argumentos.valores)

nargs="+" exige uno o más valores.

from pathlib import Path


parser.add_argument(
    "--referencia",
    default=None,
    help="Fecha de referencia en formato AAAA-MM-DD.",
)
parser.add_argument(
    "--salida",
    type=Path,
    help="Archivo opcional donde se guardará el reporte.",
)
parser.add_argument(
    "--nivel-log",
    choices=["DEBUG", "INFO", "WARNING", "ERROR"],
    default="INFO",
)

• type convierte un argumento cuando el analizador puede hacerlo claramente.
• choices limita valores permitidos.
• default define el valor si la opción se omite.
• required=True puede exigir una opción, aunque un argumento posicional suele ser más apropiado cuando el dato siempre es necesario.

python main.py --help

argparse construye el uso, la descripción y las opciones. Escribe textos de ayuda que expliquen significado y formato, no solo el nombre del argumento.

Versión débil:

help="Referencia"

Versión útil:

help="Fecha desde la cual se calcula el vencimiento, en formato AAAA-MM-DD."

argparse puede validar:

• presencia de argumentos;
• opciones permitidas;
• conversiones simples como int, float o Path;
• cantidad básica de valores.

La lógica debe validar:

• una fecha posible;
• una regla del dominio;
• coherencia entre varios argumentos;
• permisos y conflictos del sistema de archivos;
• restricciones diferentes según la operación.

No concentres toda la lógica del programa dentro de crear_parser().

Cuando la sintaxis es inválida, argparse muestra el uso y finaliza normalmente con un código distinto de cero. Ese comportamiento es apropiado para una aplicación de terminal.

No envuelvas parse_args() en un except Exception para impedirlo. Durante pruebas automatizadas puede capturarse SystemExit, pero la aplicación normal debe conservar la ayuda y el código de salida.

Registro técnico con logging

print()    → resultado o mensaje que necesita la persona usuaria
logging    → evidencia técnica para observar y diagnosticar el programa

Ejemplo:

print("Reporte creado correctamente.")
logger.info("Reporte creado en %s", ruta)

El usuario recibe una confirmación breve. El registro conserva contexto técnico.

No conviertas cada línea en INFO. Un registro útil permite localizar lo importante.

import logging


logging.basicConfig(
    level=logging.INFO,
    format="%(asctime)s | %(levelname)s | %(name)s | %(message)s",
)

logger = logging.getLogger(__name__)
logger.info("Aplicación iniciada")

En módulos propios utiliza:

logger = logging.getLogger(__name__)

La aplicación configura los manejadores una vez, normalmente cerca del punto de entrada. Los módulos solo solicitan su registrador y emiten eventos.

logging.basicConfig(
    filename="coa_toolkit.log",
    filemode="a",
    encoding="utf-8",
    level=logging.INFO,
    format="%(asctime)s | %(levelname)s | %(name)s | %(message)s",
)

filemode="a" conserva los eventos anteriores. En una aplicación real deben definirse políticas de tamaño, rotación y conservación; no se profundizará en ellas en este curso.

logger.debug("Se procesaron %d valores", cantidad)

El sistema de registro aplica el formato cuando el evento será emitido. Esta forma también separa el mensaje de sus datos.

Dentro de un except, logger.exception() incluye el traceback:

try:
    ejecutar_proceso()
except ErrorEsperado as error:
    logger.warning("Entrada rechazada: %s", error)
except Exception:
    logger.exception("Fallo inesperado durante el proceso")
    raise

Para un error esperado del usuario puede bastar warning() o error() sin traceback. Reserva logger.exception() para información que realmente ayude a diagnosticar.

Evita registrar:

• contraseñas;
• tokens;
• claves de API;
• números completos de documentos o tarjetas;
• datos personales innecesarios;
• contenido completo de archivos privados.

Registra contexto mínimo:

logger.info(
    "Operación completada: tipo=%s cantidad=%d",
    operacion,
    cantidad,
)

• configurar basicConfig() dentro de cada módulo;
• registrar y volver a registrar el mismo error en cada capa;
• utilizar ERROR para eventos normales;
• llenar el registro con datos sin utilidad diagnóstica;
• registrar secretos;
• depender del registro como única comunicación al usuario.

Uso profesional de la documentación

import argparse


print(dir(argparse))
help(argparse.ArgumentParser.add_argument)
print(argparse.ArgumentParser.add_argument.__doc__)

• dir(objeto) muestra nombres disponibles; no explica cómo utilizarlos.
• help(objeto) presenta la documentación accesible para el objeto.
• .__doc__ devuelve su docstring o None.

No llames la función cuando deseas consultar su ayuda:

help(len)    # correcto

help(len()) # intentaría ejecutar len sin argumento

## 6.2. Leer una página de referencia

Busca siempre:

1. nombre y propósito;
2. firma;
3. parámetros y valores predeterminados;
4. tipo de retorno;
5. efectos secundarios;
6. excepciones;
7. ejemplos;
8. notas de versión;
9. advertencias de seguridad o portabilidad.

## 6.3. Convertir un ejemplo en una prueba pequeña

Antes de integrar una función nueva:

from pathlib import Path

ruta = Path("demostracion.txt") print(ruta.suffix) print(ruta.with_suffix(".log"))

Utiliza datos controlados y observa tipos, retornos y modificaciones. Después adapta el ejemplo al programa real.

## 6.4. Confirmar la versión

import sys

print(sys.version) print(sys.version_info)

Si la documentación dice “Nuevo en la versión 3.x”, comprueba que el entorno del curso o del proyecto incluya esa versión. No asumas que todos los equipos ejecutan la misma.

## 6.5. Documentar lo que tú construyes

La documentación mínima del proyecto incluye:

- docstring del módulo;
- docstrings de funciones públicas;
- `--help` útil;
- `README.md` con ejemplos copiables;
- descripción de errores esperados;
- formato de entrada y salida;
- versión mínima de Python;
- decisiones que otra persona no podría deducir solo mirando una línea.

---

Videos recomendados

Los videos refuerzan temas concretos. Comprueba las firmas y comportamientos actuales en la documentación oficial.

Relaciona sus ejemplos con la separación entre un error esperado, un mensaje para el usuario y el contexto técnico.

Incluye importación completa, importación parcial, alias, espacios de nombres y flujo de ejecución al importar.

Utilízalo para observar la construcción de una interfaz real. Mantén el alcance del proyecto en argumentos y opciones sencillas.

Refuerza basicConfig(), niveles, formato, salida a archivo y la diferencia frente a print().

Utiliza estas herramientas para explorar, pero consulta también la página oficial de la función o módulo antes de integrarlo.

Documentación y recursos de lectura

• 📖Errores y excepciones
• 📖Módulos
• 📖`argparse`: referencia
• 📖Tutorial de `argparse`
• 📖`logging`: referencia
• 📖Guía básica de `logging`
• 📖Funciones integradas `dir()` y `help()`
• 📖`pydoc`: documentación y ayuda interactiva

• 📖PEP 8: guía de estilo para código Python
• 📖PEP 257: convenciones para docstrings

Nivel esencial

1. Secciones try, except, else, finally y raise del tutorial.
2. Ejecución de módulos como scripts y significado de __name__.
3. Introducción del tutorial de argparse.
4. niveles y configuración básica de logging.

Nivel de profundización

1. Encadenamiento de excepciones.
2. ruta de búsqueda de módulos.
3. objetos Logger, Handler y Formatter.
4. convenciones de docstrings públicas.

necesidad concreta
      ↓
identificar módulo u objeto
      ↓
help() / dir() para exploración rápida
      ↓
documentación oficial y versión
      ↓
prueba mínima controlada
      ↓
integración con manejo de errores
      ↓
documentar la decisión

Material descargable

El módulo incluye un proyecto inicial con:

• main.py para completar el punto de entrada;
• cli.py con la estructura de argumentos;
• operaciones.py con contratos y marcadores TODO;
• reportes.py para presentación y escritura protegida;
• configuracion.py para el registro técnico;
• errores.py con excepciones del dominio;
• plantilla de README.md;
• matriz de doce casos de prueba;
• mapa de arquitectura e importaciones;
• lista de comprobación de entrega;
• un ZIP preparado para entregar al estudiante.

El proyecto inicial no contiene la solución de las operaciones.

⬇️Descargar los materiales del Módulo 6

Errores comunes y cómo corregirlos

Glosario

Excepción: objeto que comunica una condición anormal durante la ejecución.

Manejador: bloque except que responde a un tipo de excepción.

Relanzar: permitir que una excepción continúe después de realizar una acción parcial.

Encadenamiento: relación explícita entre una excepción nueva y su causa original.

Error de dominio: problema expresado con el vocabulario y las reglas de la aplicación.

Módulo: archivo Python importable que contiene definiciones y código de nivel superior.

Espacio de nombres: relación entre nombres y objetos dentro de un ámbito.

Colisión: situación en la que dos definiciones compiten por el mismo nombre.

Efecto secundario al importar: acción externa no deseada, como imprimir, pedir datos o escribir archivos durante una importación.

Punto de entrada: lugar desde el cual comienza la ejecución coordinada de una aplicación.

Código de salida: entero que comunica al sistema si una ejecución terminó correctamente.

Argumento posicional: valor cuya ubicación en el comando determina su significado.

Opción: argumento identificado por un nombre como --salida.

Parser: componente que interpreta y valida la sintaxis de los argumentos.

Registro o log: secuencia de eventos técnicos emitidos por una aplicación.

Nivel de registro: severidad asignada a un evento, como INFO o ERROR.

Logger: objeto utilizado para emitir eventos bajo un nombre.

Handler: destino y política de entrega de los eventos de registro.

Docstring: cadena que documenta un módulo, clase, función o método.

Firma: nombre, parámetros y configuración de llamada de una función.

PEP: propuesta oficial de mejora de Python; algunas documentan convenciones y estándares.

Resumen final

En este módulo convertiste funciones aisladas en una herramienta pequeña y utilizable. Aprendiste que el manejo de errores, la modularidad, la interfaz, los registros y la documentación no son adornos posteriores: forman parte del comportamiento profesional del programa.

Ahora puedes:

• distinguir fallos esperables de errores de programación;
• limitar el alcance de un try;
• utilizar except, else y finally con intención;
• lanzar y encadenar excepciones;
• crear errores sencillos del dominio;
• dividir un programa en módulos reutilizables;
• evitar colisiones, importaciones circulares y efectos secundarios;
• proteger el punto de entrada;
• devolver códigos de salida;
• crear ayuda de terminal con argparse;
• separar resultados del usuario y registros técnicos;
• seleccionar niveles de logging;
• proteger información sensible;
• explorar con help() y dir();
• consultar documentación oficial por versión;
• escribir docstrings y un README reproducible.

• Completé las cinco prácticas guiadas.
• Entregué las siete actividades obligatorias.
• Puedo explicar cuándo no debo capturar una excepción.
• Mis bloques try contienen solo operaciones relacionadas.
• Utilicé una excepción personalizada justificada.
• Puedo explicar raise ... from error.
• Ningún módulo utiliza import *.
• Las dependencias siguen una dirección clara.
• Importar módulos no ejecuta la aplicación.
• --help explica argumentos y formatos.
• Las tres operaciones producen los resultados de control.
• El programa devuelve códigos distintos para éxito y error.
• logging se configura una sola vez.
• El registro no contiene datos sensibles.
• Los reportes no sobrescriben archivos.
• Documenté los doce casos de prueba.
• Otra persona puede seguir el README sin ayuda adicional.
• Obtuve al menos 8 de 10 en la evaluación.
• El proyecto fue aprobado.

Cuando todos los puntos estén completos, estarás preparado para iniciar el Proyecto Final Integrador de Python Práctico.