PyCharm Dedicated Python IDE

Hola, soy Alex de DEV STORIES DOT EU. PyCharm, el IDE dedicado de Python, episodio 1 de 5. Configurar manualmente un entorno de Python complejo desde cero suele generar un lío de dependencias rotas. Para cuando configuras tu language server, el linter y las path variables, ya has invertido horas solo preparándote para escribir código. El poder de un IDE dedicado: el Project Setup resuelve esto al ofrecerte un workspace unificado desde el primer clic. Antes de continuar, quiero aclarar que esta serie no está patrocinada. Todo desarrollador debería usar un editor con el que se sienta productivo. Pero hay una razón específica por la que me decidí por PyCharm para el desarrollo pesado en Python. Los editores de propósito general requieren que construyas tu propio entorno a partir de varios plugins. Un IDE dedicado a un lenguaje proporciona una integración profunda y out-of-the-box que comprende la sintaxis de Python, el package management y la project structure de inmediato. Cuando estás configurando un nuevo proyecto de Python, tu prioridad principal es el aislamiento. Si instalas las dependencias directamente en la instalación de Python de tu sistema, terminarás contaminando tus global packages y causando conflictos de versiones entre diferentes aplicaciones. Para evitar esto, necesitas un virtual environment. En PyCharm, empiezas creando un nuevo proyecto de pure Python. Proporcionas un nombre para el proyecto y un directory path. Esta es la parte que importa. En lugar de ir a la terminal para crear y activar un entorno manualmente, PyCharm te pide que configures un Python interpreter directamente en la ventana del nuevo proyecto. Seleccionas la opción para crear un nuevo virtual environment, lo apuntas a la instalación base de Python en tu máquina, y el IDE se encarga del resto. Construye el entorno aislado y lo vincula automáticamente a tu nuevo workspace. Cada vez que abres este proyecto, las dependencias correctas ya están activas. Una vez que creas el proyecto, notarás una carpeta oculta llamada dot idea en la raíz de tu workspace. La gente a menudo confunde lo que pertenece a este directorio con los global settings del propio editor. Los global IDE settings controlan cosas como tu tema visual o los atajos de teclado personalizados en todo tu trabajo. El directorio dot idea es completamente diferente. Aísla estrictamente los project-level settings. Recuerda qué virtual environment utiliza este proyecto específico, mapea las project roots y almacena los code style overrides específicos para este codebase. Como estos settings definen cómo funciona el proyecto, el directorio dot idea generalmente debería incluirse en el version control. Esto garantiza que cuando un compañero clona tu repositorio, su editor reconoce inmediatamente la project structure sin necesidad de configuración manual. Si disfrutas de estos episodios y quieres apoyar el programa, puedes buscar DevStoriesEU en Patreon. El valor principal de un IDE dedicado durante el setup es que absorbe la tediosa carga cognitiva del environment management para que puedas dedicar tu tiempo a escribir realmente business logic. ¡Gracias por escuchar, happy coding a todos!

Hola, soy Alex de DEV STORIES DOT EU. PyCharm, el IDE dedicado a Python, episodio 2 de 5. La mayoría de los desarrolladores aún recurren a la terminal para ejecutar sus tests y generar informes de coverage. No se dan cuenta de que su IDE tiene una acción integrada a un solo clic para resaltar visualmente qué líneas de código se acaban de saltar. Hoy veremos algunas joyas ocultas: Run Configurations y Code Insight. PyCharm no solo lee tu código como plain text. Parsea tu lógica estructural contra las últimas Python Enhancement Proposals, conocidas como PEPs. Si utilizas el structural pattern matching introducido en la PEP 634, el editor valida activamente tus statements match y case. Garantiza que tus patterns sean exhaustivos y te avisa si un case es unreachable. Hace exactamente lo mismo con la nueva sintaxis de type parameter de la PEP 695. El IDE detecta instantáneamente los generic type mismatches de forma nativa, mucho antes de que intentes ejecutar el código. Cuando el IDE detecta una ineficiencia o una posible mejora, te ofrece Intention Actions. Al pulsar Alt y Enter, u Option y Return en Mac, lanzas una lista de sugerencias context-aware. No se trata de simples operaciones de texto de find-and-replace. Dado que PyCharm entiende el syntax tree subyacente de tu archivo Python, puede reescribir de forma segura un nested loop complejo en una dictionary comprehension limpia sin romper tu lógica. Apunta al node específico en la estructura de tu código. Una vez que tu código está escrito y refinado, necesitas ejecutarlo. La mayoría de la gente hace clic en el botón verde de play estándar en la toolbar principal y deja de explorar ahí. Pero el widget de Run en la parte superior de la ventana tiene mucho más poder. Junto al botón de play hay un menú de More Actions, representado por tres puntos. Al abrir este menú se revelan formas totalmente distintas de lanzar tu aplicación. Aquí es donde encuentras las opciones para ejecutar tu código con el profiler o ejecutar tu test suite con el coverage activado. Muchos desarrolladores creen por error que tienen que instalar manualmente una herramienta de coverage, ejecutarla desde la command line y leer un bloque de output de la terminal para ver los resultados de sus tests. No necesitas hacer esto. PyCharm tiene el code coverage integrado directamente en el paso de ejecución. Cuando seleccionas Run with Coverage en el menú de More Actions, el IDE ejecuta la test suite en el background. Luego, superpone los resultados directamente dentro de tu editor. Obtienes marcadores verdes y rojos en el gutter, justo al lado de tus números de línea. El verde significa que la línea se testeó, el rojo significa que se omitió por completo durante la ejecución. Para que este workflow sea fluido, utiliza el popup de Run. Al pulsar Alt Shift F10 en Windows y Linux, o Control Option R en macOS, aparece un menú flotante con todas las configuraciones de tu proyecto. Aquí está la clave. No necesitas tocar el ratón para cambiar cómo se ejecuta tu app. Digamos que estás refactorizando una función masiva y compleja. Haces tus cambios estructurales usando una Intention Action. En lugar de irte a una pestaña de la terminal, abres el popup de Run, seleccionas tu test suite y la lanzas al instante con coverage. En cuestión de segundos, verificas que tu refactoring funciona y que tu nueva lógica sigue estando completamente testeada. El verdadero valor de un IDE dedicado no es solo escribir código más rápido, sino acortar el feedback loop entre cambiar una línea de código y saber exactamente cómo se comporta al ejecutarse. Gracias por pasar unos minutos conmigo. Hasta la próxima, que te vaya bien.

Hola, soy Alex de DEV STORIES DOT EU. PyCharm, el IDE dedicado a Python, episodio 3 de 5. Si tu código está plagado de instrucciones print solo para ver a qué equivale una variable, estás perdiendo horas de tiempo de desarrollo. Es hora de dejar de adivinar y empezar a observar. Hoy hablaremos sobre cómo dominar el debugger: estado y breakpoints. Imagina que estás rastreando un bug en un script de transformación de datos donde el valor de un diccionario se convierte misteriosamente en None. Si usas instrucciones print, tienes que escribir el print, ejecutar el script, leer la consola, darte cuenta de que imprimiste lo que no era, y volver a empezar. El debugger reemplaza este loop por completo. Te permite pausar la ejecución de tu programa, inspeccionar el memory heap, comprobar los valores de las variables y examinar el estado de los threads sin modificar nunca tu código fuente. Para empezar, pones un line breakpoint. Esto lo haces haciendo clic en el gutter izquierdo de tu editor, junto al número de línea donde sospechas que empieza el problema. Aparece un punto rojo. A continuación, lanzas tu script en debug mode haciendo clic en el icono del bug en lugar del botón de run estándar. Tu programa se ejecuta con normalidad hasta que alcanza tu breakpoint. La ejecución se suspende justo antes de que se ejecute esa línea de código marcada. Cuando el programa se suspende, se abre automáticamente la Debug tool window. Aquí está la clave. El Variables pane dentro de esta ventana te ofrece un mapa interactivo en tiempo real del estado de tu aplicación. Verás todas las variables que están actualmente en el scope. Puedes expandir tu diccionario para ver todas sus claves y valores en ese microsegundo exacto. También tienes acceso a la herramienta Evaluate Expression. Esto te permite ejecutar código Python arbitrario en plena ejecución. Si quieres ejecutar una list comprehension rápida en tus datos o comprobar una condición compleja, la escribes en el evaluator. Este la procesa utilizando el estado actual de la aplicación y devuelve el resultado. Incluso puedes usar esta herramienta para sobrescribir el valor de una variable sobre la marcha, probando una posible solución ahí mismo sin reiniciar la debug session. También puedes consultar el Frames pane, que representa tu call stack. Muestra la secuencia exacta de llamadas a funciones que te llevaron a tu breakpoint actual. Seleccionar un frame diferente te permite inspeccionar las variables locales de las funciones que llamaron a tu código actual. Una vez pausado, tienes que avanzar la ejecución línea por línea para aislar el momento en que el valor del diccionario se convierte en None. A esto se le llama stepping. Los desarrolladores suelen confundir el step over con el step into. Step Over significa ejecutar la línea actual y pausar en la siguiente línea del archivo actual. Si la línea actual contiene una llamada a una función, Step Over ejecuta toda esa función en segundo plano y te deja en la siguiente línea de tu archivo activo. Lo usas cuando confías en que la función funciona correctamente. Step Into significa sumergirse dentro de la llamada a la función. El debugger mueve la ejecución a la primera línea de esa función recién llamada, permitiéndote rastrear su lógica interna línea por línea. Al usar breakpoints y stepping, tú controlas el flujo. Pausas justo antes del posible error, haces step into en la función de transformación, y observas cómo se actualiza el Variables pane. La línea exacta que se ejecuta justo antes de que el valor del diccionario se convierta en None es el origen de tu bug. El debugger no es solo una herramienta para encontrar crashes. Es una lente interactiva que te da autoridad absoluta sobre el flujo de tu programa y el memory state. Eso es todo por este episodio. Gracias por escuchar, ¡y sigue programando!

Hola, soy Alex de DEV STORIES DOT EU. PyCharm, el IDE dedicado a Python, episodio 4 de 5. El código async hace que tus aplicaciones sean increíblemente rápidas, hasta que un deadlock silencioso lo congela todo sin dejar absolutamente ningún rastro de error. Averiguar exactamente qué coroutine está bloqueada es francamente difícil. La solución en PyCharm es visualizar el código async: el Concurrency Diagram. El código async es difícil de debuggear porque un único event loop cambia constantemente entre tareas. Si creas un web scraper async y de repente tarda diez minutos en ejecutarse en lugar de diez segundos, el logging estándar es prácticamente inútil. Los print statements solo generan un muro caótico de texto intercalado. Sabes que una tarea está en espera, pero no sabes cuál ni por qué. Podrías pensar que aquí necesitas un CPU profiler estándar. Pues no. Un CPU profiler estándar te indica qué función consumió más potencia de procesamiento. La feature de concurrency visualization es diferente. Es una herramienta especializada, diseñada específicamente para rastrear los estados de los threads y los event loops de asyncio a lo largo del tiempo. Te muestra cuándo tu código no está haciendo absolutamente nada. Accedes a esta feature a través del widget de Run en la parte superior de tu IDE. Abre el menú de More Actions de tu run configuration y elige la opción de hacer profile con Concurrency Visualization. PyCharm ejecuta tu código y luego genera un diagrama detallado en una tool window dedicada. Dentro de esta ventana, selecciona la pestaña del Asyncio graph. Aquí es donde se produce la visualización real. La interfaz muestra un timeline. Cada pista horizontal representa un event loop o un thread. A lo largo de estas pistas, PyCharm traza bloques que representan tus coroutines. La longitud de un bloque indica cuánto tiempo existió la coroutine. Aquí es donde se pone interesante. Cada bloque en el timeline está codificado por colores según su estado exacto en ese milisegundo específico. Un color indica que la coroutine se está ejecutando activamente y utilizando la CPU. Otro color muestra cuándo está esperando, por ejemplo, una respuesta de red o la lectura de un archivo. Un color diferente resalta cuando un thread está completamente bloqueado. Aplica esto al escenario del web scraper atascado. En lugar de adivinar por qué el scraper se ha quedado bloqueado, ejecutas la concurrency visualization. Observas el Asyncio graph y ves diez coroutines lanzadas para obtener páginas web. Nueve de ellas aparecen como un bloque sólido de un color de espera. Puedes hacer clic en esos bloques para ver exactamente qué función representan. Inmediatamente te das cuenta de que todas están bloqueadas, esperando un único network lock que una coroutine anterior no pudo liberar. Ver estos estados en tiempo real de forma nativa en el IDE supone una ventaja enorme sobre el debugging manual. Cambia tu perspectiva: pasas de leer líneas de código secuenciales a visualizar relaciones temporales reales. Detectas los deadlocks no rastreando errores lógicos mentalmente, sino identificando físicamente los colores bloqueados y los espacios vacíos en un gráfico visual. La conclusión más importante es que los bugs async suelen ser problemas de timing y estado, y el concurrency diagram traduce esos problemas de timing invisibles en un mapa visual claro. Gracias por dedicarme unos minutos. Hasta la próxima, cuídate.

Hola, soy Alex de DEV STORIES DOT EU. PyCharm, el IDE dedicado a Python, episodio 5 de 5. Compartir pantalla está bien para presentaciones, pero cuando una migración de base de datos compleja falla en local, señalar un streaming de vídeo no sirve de nada. Los dos necesitáis tener las manos en el teclado, interactuando directamente con el entorno roto. Eso es exactamente lo que resuelve el Swarm Programming usando JetBrains Code With Me. Code With Me es una feature integrada para el desarrollo colaborativo en remoto. Convierte tu IDE local en un workspace compartido para Swarm Programming, mentoring y collaborative debugging. Imagina un escenario donde un compañero junior está peleándose con una migración de base de datos que solo falla en el setup de su máquina local. En lugar de hacer que haga push de código roto, o intentar guiarle con comandos de terminal por una llamada, puede iniciar una sesión remota directamente desde su IDE. El setup tiene una relación clara de host y guest. El host es la persona que comparte su proyecto. Debe tener PyCharm instalado y ejecutándose. Existe el falso mito de que cualquiera que se una a la sesión también necesita su propia licencia de pago de PyCharm. Pues no. Los guests simplemente reciben un link de invitación generado por el host. Cuando haces clic en ese link como guest, tu navegador descarga y abre automáticamente el JetBrains Client. Esta es una aplicación ligera que se ve y se comporta casi exactamente como un IDE de PyCharm completo, pero no procesa nada en local. Todo el trabajo pesado, el indexing y el syntax checking ocurren en la máquina del host. Tienes la experiencia de programación nativa completa sin necesitar tener el código fuente clonado en tu disco duro. Cuando abres tu máquina a otro developer, la seguridad y los límites importan. El host tiene un control granular sobre lo que los guests pueden hacer. Esto lo configuras antes de generar el link. El acceso Read-only significa que el guest puede ver los archivos y seguir tu cursor, pero no puede cambiar nada. El acceso Edit files les permite escribir junto a ti en tiempo real. El Full access entrega las llaves, permitiendo al guest ejecutar código, pasar tests e interactuar directamente con tu terminal local. Puedes cambiar estos permisos sobre la marcha durante la sesión. Aquí está la clave. No solo estás compartiendo archivos de texto; estás compartiendo el runtime environment. Si el developer junior ejecuta un servidor web local en el puerto 8000 para probar su migración, el developer senior remoto normalmente no puede acceder a él. Code With Me incluye una feature de port forwarding para solucionar esto. El host especifica un puerto local para compartir. El JetBrains Client entonces hace bind de ese mismo puerto en la máquina del guest. El developer senior puede abrir su propio navegador web local, navegar a localhost puerto 8000, e interactuar con la aplicación que se está ejecutando en la máquina del host. El collaborative debugging funciona mejor cuando eliminas la fricción de reproducir un estado roto. Con Code With Me, te saltas el setup del entorno por completo y solucionáis el problema real juntos, exactamente donde vive. Con esto terminamos nuestra serie. Te animo a leer la documentación oficial de JetBrains, probar estas herramientas de forma práctica, o visitar devstories dot eu para sugerir temas para futuras series. Gracias por pasar unos minutos conmigo. Hasta la próxima, cuídate.