Editores e IDEs: qué hacen realmente con tu código

Cuando abres un archivo .py en VSCode o PyCharm, no estás usando una herramienta mágica que “entiende” Python. Estás usando un programa que analiza texto, aplica reglas, y te muestra el resultado visualmente. Entender eso cambia cómo aprovechas estas herramientas.

Un editor de texto (Sublime Text, Notepad++, incluso el propio VSCode en su forma más desnuda) manipula caracteres. No sabe si escribes Python, JavaScript o la letra de una canción. Un IDE (Integrated Development Environment) añade capas encima: entiende la estructura del lenguaje, puede ejecutar tu código, depurarlo, gestionar dependencias, y conectar todo eso en una sola interfaz. La diferencia no es filosófica, es funcional: un IDE corre herramientas especializadas en segundo plano que un editor puro no tiene.

Lo interesante es que esta línea se ha vuelto borrosa. VSCode es técnicamente un editor, pero con las extensiones correctas se comporta como un IDE completo. PyCharm es un IDE desde el primer arranque. Ninguno de los dos “ejecuta” tu código mientras escribes — lo que hacen es análisis estático: leer el texto de tu archivo sin ejecutarlo y sacar conclusiones sobre su estructura.

Si instalas la extensión oficial de Python en VSCode, activas Pylance como servidor de lenguaje (Language Server). Un servidor de lenguaje es un proceso separado que habla un protocolo estándar (LSP) con el editor. Pylance analiza tu código continuamente, resuelve importaciones, infiere tipos, y devuelve al editor información como “esta variable es un list[str]” o “este método no existe en este objeto”. El editor simplemente muestra esa información. Si mañana aparece un servidor de lenguaje mejor, puedes sustituirlo sin cambiar el editor.

El debugger integrado es otra pieza distinta: es un adaptador que habla con el intérprete de Python usando debugpy por debajo. Cuando pones un breakpoint, el editor le dice a debugpy “pausa aquí”, y debugpy detiene el proceso de Python y expone el estado de las variables. No es magia del editor — es comunicación entre procesos.

PyCharm hace todo eso de fábrica, más análisis de flujo de datos más profundo, refactorizaciones automáticas seguras (renombrar un símbolo en todos los archivos del proyecto sin romper nada), y una integración más estrecha con herramientas como pytest, bases de datos o frameworks web. El precio es que arranca más lento, consume más RAM, y su configuración es menos transparente.

Tres conceptos que verás en cualquier entorno:

• Linting: un linter (Pylint, Flake8, Ruff) recorre tu código buscando patrones problemáticos — variables no usadas, imports mal ordenados, indentación inconsistente. Te avisa antes de que ejecutes nada.
• Autocompletado: sugiere continuaciones basándose en el tipo inferido del objeto. Si Pylance sabe que x es un dict, te ofrece .keys(), .values(), etc.
• Type checking: herramientas como Mypy o el propio Pylance en modo estricto verifican que los tipos que declaras (con type hints) sean coherentes. Si una función espera un int y le pasas un str, te lo marca en rojo antes de ejecutar.

# editor_demo.py
# Ejemplo que activa deliberadamente las tres herramientas anteriores.

def greet(name: str) -> str:
    message = f"Hola, {name}!"
    return message

def add(a: int, b: int) -> int:
    return a + b

# El linter (Ruff/Flake8) detectaría una variable sin usar:
# unused = 42

# El type checker (Pylance/Mypy) marcaría esta llamada como error
# porque add() espera int, no str:
# result = add("dos", "tres")

# Esto es correcto: tipos coherentes, autocompletado funciona.
total = add(10, 20)
greeting = greet("mundo")

# str.upper() aparece en autocompletado porque Pylance sabe
# que greet() devuelve str.
print(greeting.upper())
print(total)

Fíjate en los type hints (name: str, -> str, a: int). No cambian cómo Python ejecuta el código — Python los ignora en tiempo de ejecución. Existen exclusivamente para que herramientas de análisis estático como Pylance puedan razonar sobre tu programa sin ejecutarlo. Cuando escribes greeting.upper(), el autocompletado funciona porque Pylance leyó la firma de greet(), dedujo que devuelve str, y sabe qué métodos tiene str. Sin el hint -> str, tendría que adivinar (o rendirse y poner Unknown).

El linter y el type checker son procesos separados del intérprete. Puedes tener código que el linter odia pero que Python ejecuta perfectamente, y viceversa. Son filtros de calidad que corren antes de que toques el botón de play.

Errores que debes conocer

Error: Instalar la extensión de Python pero que el autocompletado no funcione porque VSCode está usando el intérprete del sistema en vez del virtual environment del proyecto.

# ❌ El import no se resuelve, Pylance muestra "Import 'requests' could not be resolved"
# aunque hiciste: pip install requests

import requests  # rojo en VSCode

# ✅ Selecciona el intérprete correcto con Ctrl+Shift+P → "Python: Select Interpreter"
# y elige el que apunta a tu .venv o entorno activo.

import requests  # ahora Pylance lo encuentra y el autocompletado funciona

Pylance busca los paquetes instalados en el intérprete seleccionado. Si seleccionas el Python del sistema y tu proyecto está en un venv, Pylance no ve lo que instalaste.

Error: Confundir un error del linter con un error de Python. El linter marca algo en amarillo o rojo, el desarrollador cree que el código no funciona, y lo cambia innecesariamente.

# ❌ El linter avisa: "line too long (92 > 79 characters)" [E501]
# No es un error de Python. El código funciona perfectamente.
nombre_muy_largo_de_variable = "esto es una cadena bastante larga que supera el límite de PEP 8"

# ✅ Puedes acortarlo para cumplir la guía de estilo, o configurar el linter
# para ignorar esa regla si tu equipo usa un límite distinto.
nombre_corto = (
    "esto es una cadena bastante larga "
    "que ahora respeta el límite de línea"
)

Los warnings del linter son sugerencias de estilo o posibles problemas, no errores del intérprete. Aprende a distinguir el color/ícono que usa tu editor para cada tipo de diagnóstico.

N° 13