Mostrando las entradas con la etiqueta Reflexión. Mostrar todas las entradas
Mostrando las entradas con la etiqueta Reflexión. Mostrar todas las entradas

3 de noviembre de 2018

PCAP: Certificación de Python a nivel asociado

Hace unos meses escribí en este blog una entrada sobre la certificación de introducción a la programación usando Python ofrecida por Microsoft. Ahí mencioné también otra certificación de Python, pero en este caso de tipo vendor-neutral (independiente de proveedor), titulada Certified Associate in Python Programming, la cual aún no estaba disponible en aquel momento. En marzo de 2018, el recientemente creado OpenEDG Python Institute finalmente lanzó el respectivo examen de certificación.

Fuente: pythoninstitute.org

En esta entrada del blog de EduPython voy a presentar algunos de los detalles más relevantes de esta nueva certificación, así como mi experiencia en todo el proceso para obtenerla.

Generalidades

El sitio oficial incluye la siguiente descripción:
La certificación como programador de Python a nivel asociado (PCAP por sus siglas en inglés) es una credencial profesional que mide la capacidad de un individuo para realizar tareas de codificación relacionadas con los conceptos básicos de la programación en el lenguaje Python y las nociones y técnicas fundamentales utilizadas en la programación orientada a objetos.

La certificación demuestra que una persona está familiarizada con los conceptos fundamentales de programación de computadoras: sintaxis y semántica del lenguaje Python, ejecución condicional, ciclos, entorno de ejecución, y técnicas de codificación estructurada y orientada a objetos.
La obtención de la certificación PCAP es evidencia de que alguien está plenamente familiarizado con los recursos principales provistos por Python 3, y esto servirá como punto de partida para estudios más avanzados y el inicio de una carrera como desarrollador de software.


Información sobre el examen

  • Nombre del examen: PCAP Certified Associate in Python Programming
  • Clave: PCAP-31-02
  • Nivel: Asociado
  • Certificaciones relacionadas: 
    • PCPP Certified Professional in Python Programming (aún no disponible a la fecha)
  • Requisitos previos: Ninguno
  • Duración: 65 minutos
  • Número de preguntas: 40
  • Calificación mínima para aprobar: 70% (28 aciertos)
  • Formato del examen: Preguntas de opción múltiple con una o varias respuestas
  • Idioma: Inglés
  • Costo: USD 295.00 (con posibilidad de un descuento del 50%, ver descripción más adelante)
  • Lugar donde se presenta: en cualquiera de los cinco mil centros de evaluación autorizados de Pearson VUE alrededor de todo el mundo.

Objetivos del examen

Los interesados en la certificación PCAP deben demostrar conocimiento sobre los siguientes conceptos:
  1. Los fundamentos de la programación de computadoras, es decir, cómo funciona la computadora, cómo se ejecuta un programa, cómo se define y construye el lenguaje de programación, cuál es la diferencia entre compilación e interpretación, qué es Python, cómo se compara con otros lenguajes de programación, y cuáles son las diferencias más importantes entre las principales versiones de Python. 
  2. Los métodos básicos de formato y salida de datos ofrecidos por Python, junto con los tipos principales de datos y operadores numéricos, sus relaciones mutuas y enlaces; el concepto de variables y las convenciones para nombrarlas; el operador de asignación, las reglas que rigen la construcción de expresiones; la entrada y conversión de datos.
  3. Valores booleanos para comparar valores de diferencia y controlar los caminos de ejecución utilizando las instrucciones if e if-else; la utilización de ciclos (while y for) y cómo controlar su comportamiento utilizando las instrucciones break y continue; la diferencia entre operaciones lógicas y de manipulación de bits; el concepto de listas y sus mecanismos de procesamiento, incluyendo la iteración proporcionada por el ciclo for y las rebanadas (slices); la idea de arreglos multidimensionales.
  4. La definición y el uso de funciones: su justificación, propósito, convenciones y trampas; el concepto de pasar argumentos de diferentes maneras y establecer sus valores predeterminados, junto con los mecanismos para devolver los resultados de la función; alcance o visibilidad de nombres; datos compuestos adicionales: tuplas y diccionarios, y su función en el procesamiento de datos.
  5. Módulos de Python: justificación, función, cómo importarlos de diferentes maneras e identificar el contenido de algunos módulos estándar proporcionados por Python; la forma en que los módulos se acoplan para hacer paquetes; el concepto de una excepción y la implementación de Python de las excepciones, incluida la instrucción try-except, con sus aplicaciones, y la instrucción raise; cadenas de caracteres y sus métodos específicos, junto con sus similitudes y diferencias en comparación con las listas.
  6. Los fundamentos de la POO (programación orientada a objetos) y la forma en que se adoptan en Python, mostrando la diferencia entre la POO y el enfoque procedural clásico; las características típicas de objetos: herencia, abstracción, encapsulación y polimorfismo, junto con las particularidades de Python como variables de instancia y de clase, así como la implementación de herencia en Python; las excepciones como objetos; los generadores de Python (la instrucción yield) y las cerraduras léxicas (la palabra reservada lambda); los mecanismos para procesar (crear, leer y escribir) archivos.
También está disponible el temario más detallado del examen.

Fuente: www.123rf.com

Recursos para estudiar

El Python Institute recomienda cualquiera de las siguientes dos opciones para que los interesados puedan prepararse adecuadamente para presentar el examen PCAP:
  • Autoestudio: Curso en línea PCAP: Programming Fundamentals in Python. Este es un curso gratuito que consta de dos partes (cinco módulos en total) y está disponible desde la plataforma educativa de OpenEDG. Cada estudiante inscrito al curso avanza a su propio ritmo, pero debe ir cubriendo los contenidos y exámenes de cada módulo dentro de ciertas fechas que son establecidas al momento de inscribirse. Cada una de las dos partes del curso tiene una duración estimada de 40 horas y se deben concluir en no más de siete semanas. Si el estudiante realiza todos sus exámenes de los módulos dentro de las fechas previamente fijadas y además obtiene una puntuación igual o superior al 70% en el examen final entonces se hace acreedor a un vale de descuento del 50% sobre el costo regular del examen en los centros de evaluación Pearson VUE. Esto quiere decir que en lugar de tener que pagar USD 295.00, el costo del examen queda en USD 147.50 ya con el descuento. El curso no requiere conocimientos previos de programación.
  • Curso presencial: Cisco Networking Academy cuenta con un curso de 70 horas de duración titulado PCAP: Programming Essentials in Python el cual es impartido por un instructor de manera presencial. Los cursos ofrecidos por Cisco tienen un costo, el cual es determinado por la institución académica que los imparte (usualmente alguna escuela o universidad). Cuando un estudiante termina el curso de manera exitosa se lo otorga un vale de descuento del 51% en el examen de certificación, quedando su costo en USD 144.55. La página oficial indica que el curso solo se ofrece en inglés lo que me hace suponer que aún no está disponible en países de habla hispana. Al igual que la opción de autoestudio, este curso tampoco requiere conocimientos previos de programación.


Yo me preparé por mi cuenta para el examen utilizando el curso en línea de OpenEDG. El curso está 100% alineado al examen de certificación, por lo que sirve como un muy buen repaso pero además me ayudó a descubrir aquellos rincones recónditos del lenguaje que ni siquiera sabía que ignoraba, aún a pesar de tener años de experiencia programando en Python. Dado que la mayor parte del contenido me resultaba familiar, lo que hice fue irme directamente a resolver los exámenes de cada módulo. Si me daba cuenta de que había temas en los que tenía algunas dudas, entonces ya optaba por revisar con más detalle los contenidos correspondientes. Bajo este esquema pude prepararme en relativamente poco tiempo. Cabe mencionar que sí me topé con uno que otro error en el contenido del curso, pero nada demasiado grave. Lamentablemente, no hallé en el sitio algún mecanismo para reportar este tipo de problemas.

El sitio oficial del Python Institute tiene disponible un examen de práctica completo (documento PDF) muy parecido al examen real de certificación PCAP. Una pregunta ejemplo tomada de este mismo documento es la siguiente:
What is the expected output of the following snippet?

    i = 250
    while len(str(i)) > 72:
        i *= 2
    else:
        i //= 2
    print(i)

A) 125
B) 250
C) 72
D) 500
La respuesta de la pregunta anterior es A. Si esto no resulta evidente, recomiendo al lector leer otra entrada de mi blog titulada: ¿Dónde quedó el do-while?.

Presentando el examen

Como ya mencioné anteriormente, el examen PCAP se presenta en cualquier centro de evaluación autorizado de Pearson VUE. Es necesario agendar el examen desde su sitio oficial con al menos 24 horas hábiles de anticipación. Ahí mismo se realiza el pago mediante el cargo a una tarjeta de crédito internacional. Durante este proceso se debe proporcionar también el vale de descuento en caso de contar con él.

Pare presentar el examen se recomienda llegar con 15 minutos de antelación al centro de evaluación. Si se llega tarde a la cita el examen se cancela y no hay reembolsos. Al llegar al centro de evaluación el candidato a presentar el examen debe mostrar dos identificaciones vigentes con su nombre y firma, y al menos una de éstas debe ser de emisión gubernamental y contar con foto de la persona.

Fuente: myupdatestar.com

Una vez registrado el candidato se le lleva a un cuarto de examen. No se permite introducir a dicha habitación ningún artículo personal, incluyendo bolsas, libros, notas, teléfono, reloj, ni cartera. El centro de evaluación debe proporcionar un lugar seguro para guardar todos estos objetos. El cuarto tiene la computadora para hacer el examen y una cámara de vigilancia para monitorear al candidato en todo momento y verificar que no haga trampa. La computadora solo puede correr el software para administrar el examen. No hay acceso a Internet ni a ningún otro programa. Al candidato se le brinda un pequeño pintarrón (pizarrón blanco) y un plumón para escribir sobre éste. Lo anterior es por si se requiere hacer algún tipo de cálculo o corrida de escritorio durante el examen. Durante el examen no está permitido salir del cuarto, hablar con alguien más, ni tampoco consumir alimentos o bebidas.

Ya en la computadora, se tienen que aceptar desde un inicio un acuerdo de confidencialidad en donde en esencia el candidato se compromete a no divulgar el contenido del examen. Luego viene un breve tutorial de cómo utilizar el software que se usará para presentar el examen. Lo anterior tiene una duración de unos 10 minutos y no forma parte de los 65 minutos que dura el examen en sí.

Una vez comenzado el examen, la parte superior de la pantalla informa cuánto tiempo queda disponible y cuántas preguntas faltan por responder. Mientras uno esté dentro del tiempo permitido del examen, y no haya seleccionado la opción de concluirlo, es válido navegar de ida y vuelta entre las preguntas, contestarlas en cualquier orden y modificar las respuestas. Al seleccionar la opción de terminar el examen aparece un resumen en donde se nos avisa si alguna pregunta quedó sin contestar para que la podamos responder (si es que aún hay tiempo). Al concluir, el sistema brinda unos minutos para realizar comentarios sobre cualquiera de las preguntas del examen, pero ya sin tener la oportunidad de cambiar nuestras respuestas. Esto es totalmente opcional, y sirve para reportar situaciones en donde uno considera que existe un error o ambigüedad en la redacción de alguna pregunta o en sus incisos de respuesta.

Reporte con el resultado del examen PCAP.

Concluido todo lo anterior el candidato debe retirarse del cuarto de examen para dirigirse con la persona del centro de evaluación responsable del registro y administración del examen quien entregará una hoja impresa con el reporte del resultado del examen. Éste contiene la puntuación total del examen (en porcentaje) y los resultados del aprendizaje desglosado en cuatro secciones (cada sección fue conformada por diez preguntas):
  1. Control y evaluaciones
  2. Colecciones de datos
  3. Funciones y módulos
  4. Clases, objetos y excepciones
Así mismo, el reporte incluye una liga oficial de Pearson VUE junto con un número de validación para verificar que el reporte sea legítimo. Este dato puede ser útil, por ejemplo, para un empleador que desee confirmar de manera fácil y rápida las credenciales de un aspirante a un puesto de trabajo.

A mi parecer, el momento de más nervios de todo este proceso ocurre en los minutos que pasan entre el instante en que uno termina el examen y el cuando finalmente te entregan el reporte impreso con tu resultado. Muchas cosas pueden pasar por tu mente en ese tiempo. Afortunadamente, en este examen obtuve un muy buen resultado. Solo tuve una pregunta incorrecta de las cuarenta que conforman el total del examen, logrando así una puntuación del 97%. Sinceramente, el examen se me hizo relativamente fácil a partir de la preparación que tuve. Mi apreciación es que los exámenes de módulos y el examen final del curso en línea provisto por el Python Institute tienen un nivel de dificultad mayor al del examen real.

Certificado de PCAP

Seis días después me llegó por correo electrónico una confirmación del resultado de mi examen junto con una liga hacia mi expediente digital de OpenEDG de donde pude descargar la versión electrónica del certificado. Como mes y medio después me llegó por correo convencional un paquete desde Polonia, bastante traqueteado por cierto, con la versión en papel de mi certificado junto con una carta de felicitación y una pulsera de plástico azul alusiva al PCAP.

Tal como lo mencioné en la entrada de la certificación de Microsoft, para mí una certificación es un medio de superación personal que sirve para validar y complementar mis habilidades y conocimientos, ya que me motiva a prepararme en temas particulares que de otra forma difícilmente revisaría por mi cuenta. En este sentido veo bastante útil la obtención de la certificación PCAP.


1 de agosto de 2018

Cuando el dictador se jubila

En días pasados recibí un correo electrónico de Jaime Tovar, un destacado ex-alumno mío que actualmente trabaja en el Reino Unido como desarrollador de software sénior. En su mensaje me dio la noticia de que Guido van Rossum había renunciado un día antes a su rol de BDFL (siglas en inglés de “dictador benevolente de por vida”) del lenguaje Python. Jaime me sugirió que escribiera una entrada en este blog para dar a conocer mi opinión al respecto. Inicialmente no estaba muy convencido de que pudiera aportar algún comentario interesante a este hecho, pero después de pensar varios días me di cuenta de que sí tengo algunas reflexiones que puedo compartir con mis apreciables lectores.

Guido van Rossum, creador de Python.
Fuente: www.gacetaholandesa.com

Antecedentes

Guido van Rossum comenzó a escribir la primera implementación del lenguaje Python en diciembre de 1989. Desde aquel entonces, Guido había sido el líder moral indiscutible de la comunidad de Python y el encargado de dirigir la evolución del lenguaje. En 1995, a manera de broma, se le otorgó a Guido el título de “primer BDFL interino”.

Guido (centro) en la primera conferencia de Python en el
Instituto Nacional de Estándares y Tecnología (NIST),
noviembre de 1994 en Gaithersburg, Maryland.
Fuente: legacy.python.org

Pero, ¿qué es exactamente un BDFL? La wikipedia provee la siguiente definición:
BDFL es un título informal que se otorga a ciertos individuos de la comunidad de desarrolladores de software de código abierto que tienen la tarea de asignar las directrices generales y, en ciertas situaciones, las decisiones finales dentro del ámbito de un proyecto. La traducción de Benevolent Dictator for Life es Dictador Benevolente De por vida, lo que conlleva un tanto de informalidad y humor. 
Después de Guido han habido otras personas con el título de BDFL otorgado por parte de sus respectivas comunidades, por ejemplo Linus Torvalds (creador del núcleo o kernel de Linux) y Yukihiro Matsumoto (creador del lenguaje Ruby), por mencionar a un par.

Fuente: image.thmeythmey.com

En su ensayo titulado “Cultivando la noosfera”, Eric Raymond explica cómo la naturaleza del código abierto obliga a que una “dictadura” sea benevolente. Cuando un proyecto se enfrenta a una situación difícil se espera que su BDFL escuche y evalúe pacientemente los argumentos de todas las partes involucradas y finalmente tome la decisión que resulte más conveniente para los intereses de toda la comunidad. Sin benevolencia un desacuerdo mayor puede ocasionar una bifurcación (fork). En este caso una persona o grupo toma el código fuente del proyecto (que al ser abierto cualquiera tiene acceso a él) y comienzan a extenderlo y modificarlo en una dirección distinta a la original. Esto ha ocurrido varias veces en el pasado, por ejemplo cuando MySQL fue bifurcado para crear MariaDB en 2009. Esto fue debido a las preocupaciones que tenían algunos de los desarrolladores principales con respecto a la adquisición anunciada de Sun Micrsoystems (dueños en ese momento de MySQL) por parte de Oracle. La comunidad temía que Oracle, la compañía de bases de datos relacionales más grande del mundo, tuviera como objetivo eliminar eventualmente a MySQL y reducir así su competencia.

Un BDFL usualmente es el autor original de un proyecto. Esto significa que, por lo general, esta persona cuenta con un nivel técnico que otros respetan e incluso admiran. Sin embargo, su destreza tecnológica es tan solo una de varias cualidades que debe tener un buen BDFL. El reto principal de un líder de un proyecto de código abierto es lidiar con personas y coordinarlas, y esto resulta complicado debido a que la mayoría (o incluso todos) son voluntarios y no reciben remuneración económica alguna por su participación. Aquí el respeto, el agradecimiento y el reconocimiento juegan un papel fundamental.

Fuente: www.sieuthichungcu.info

En el año 2009, como broma de April Fool´s Day (equivalente al día de los santos inocentes en muchos países de habla hispana), se coqueteó con la posibilidad de la abdicación de Guido como BDFL. En esa ocasión se presentó el PEP 401 en donde se nombraba a Barry Warsaw como sucesor de Guido. En lugar de BDFL, el título de Barry iba a ser FLUFL (Friendly Language Uncle For Life,  o “tío amistoso del lenguaje de por vida”). Es importante enfatizar que esta noticia tan solo fue una broma de un 1º de abril. Sin embargo, ¿sería esto un augurio de lo que ocurriría casi una década después?

Barry Warsaw, el FLUFL o
“tío amistoso del lenguaje
de por vida”.
Fuente: hwww.linkedin.com

NOTA: Un PEP, o Python Enhancement Proposal, es un documento oficial de la comunidad de Python en el que se informa de una propuesta para mejorar el lenguaje o algún proceso. Posterior a la publicación de un PEP, los miembros de la comunidad discuten sobre la viabilidad de la propuesta y ofrecen sugerencias. La decisión final para aprobar un PEP corre a cargo del BDFL o, en su defecto, por algún delegado del BDFL. Todos los cambios relevantes que ocurren en Python comienzan con uno o varios PEPs. Tristemente, como veremos en un momento, fue a consecuencia de las reacciones negativas que recibió después de aceptar un PEP que Guido optó por anunciar su retiro como BDFL.


La noticia

El pasado jueves 12 de julio, Guido van Rossum comunicó lo siguiente a través de la lista de correo de python-committers:
Asunto: Transferencia de poder

Ahora que está concluido el PEP 572 ya no quiero tener que pelear por un PEP y descubrir que mucha gente detesta mis decisiones.

Quiero descartarme por completo del proceso de toma de decisiones. Seguiré allí por un tiempo como cualquier otro desarrollador del núcleo de Python, y todavía estaré disponible para guiar a las personas, posiblemente ahora con mayor disponibilidad. Pero básicamente me estoy dando unas vacaciones permanentes del puesto de BDFL, y ahora todos ustedes estarán por su propia cuenta.

Esto iba a suceder eventualmente de cualquier manera. Aún está ese autobús al acecho a la vuelta de la esquina, y no me estoy haciendo más joven... (evitaré compartirles mi lista de problemas médicos).

No voy a nombrar un sucesor.

Entonces, ¿qué van a hacer? ¿Crear una democracia? ¿Una anarquía? ¿Una dictadura? ¿Una federación?

No me preocupan las decisiones cotidianas que surgen del sistema de seguimiento de incidentes o desde GitHub. Raramente solicitan mi opinión, y por lo general no es realmente importante. Así que esto continúa como siempre.

Las decisiones que más importan probablemente son:
  • ¿Cómo se deciden las PEPs?
  • ¿Cómo iniciar a los nuevos desarrolladores del núcleo de Python?
Es posible que podamos escribir procesos para estas cosas vía PEPs (quizás dichas PEPs podrían conformar una especie de constitución). Pero hay un truco aquí. Voy a dejar que todos ustedes (los autores de los “commits”) lo resuelvan por sí mismos.

Tengan en cuenta que aún existe un código de conducta. Si no les gusta dicho documento, la única opción podría ser dejar este grupo voluntariamente. Quizás hay detalles aún por decidir, por ejemplo: ¿cuándo debería ser expulsada alguna persona? (esto implica restringirle el acceso a las listas de correo de python-dev o python-ideas, ya que éstas también están cubiertas por el código de conducta).

Finalmente, un recordatorio de que los registros de esta lista son públicos (https://mail.python.org/pipermail/python-committers/) aunque la membresía es restringida (limitada solamente a los desarrolladores del núcleo de Python). Todavía estaré aquí, pero estoy intentado dejar que todos ustedes resuelvan algo por su propia cuenta. Estoy cansado y necesito un descanso muy largo.

— Guido van Rossum (python.org/~guido)
El PEP 572 al que Guido se refiere al inicio de su comunicado es sobre “Expresiones de asignación”, un cambio previsto para ser incorporado en la versión 3.8 del lenguaje que está programada a ser liberada en octubre de 2019. Actualmente, las asignaciones a variables en Python deben realizarse usando un enunciado (statement) de asignación. Veamos el siguiente ejemplo:
# Código para Python 3.0 y superior
r = input('¿Deseas continuar? (s/n) ')     # 1  
while r in 'Ss':                           # 2
    print('Tu respuesta fue:', r)          # 3
    print('Continuando...')                # 4
    r = input('¿Deseas continuar? (s/n) ') # 5
Las líneas 1 y 5 son enunciados de asignación. De hecho, son exactamente el mismo enunciado. Esta duplicación es necesaria aquí dado que Python no cuenta con un enunciado do-while y el valor de la variable r es requerida tanto en la condición (línea 2) como en el cuerpo (línea 3) del enunciado while.

El PEP 572 introduce un nuevo operador de asignación := (un signo de dos puntos seguido de un signo de igual) que permite realizar asignaciones dentro de una expresión. Este nuevo operador es esencialmente equivalente al operador de asignación = (un signo de igual) soportado por los lenguajes basados en C (C++, C#, Java, JavaScript, etc.). Ahora con el operador de asignación := el código de arriba podría quedar escrito de manera más compacta así:
# Código para Python 3.8
while (r := input('¿Deseas continuar? (s/n) ')) in 'Ss': # 1
    print('Tu respuesta fue:', r)                        # 2
    print('Continuando...')                              # 3
Hay que notar que la asignación de r se realiza ahora dentro de la misma expresión condicional del enunciado while (línea 1) reduciendo con ello dos líneas del programa. Cada vez que se realiza la condición del while, se realiza primero la re-asignación de la variables r.

A muchas personas no le gustó esta adición al lenguaje. Hubo a quienes simplemente no les gustó la sintaxis del nuevo operador. A muchos otros no les gustó en absoluto la idea de tener una forma alternativa de realizar asignaciones de variables por considerar que estaba quebrantando el Zen de Python, el cual es una serie de principios de software que influyen en el diseño del lenguaje.

La gente en desacuerdo comenzó a compartir su opinión al respecto con poca mesura, tanto a Guido como a la Internet. Y así fue como se abrió esta pequeña caja de Pandora.

Pandora's Box by Arthur Rackham
“Caja de Pandora” de Arthur Rackham.
Fuente: talesfortadpoles.ie

Francamente, a mí no me gustó al principio la propuesta ni la sintaxis seleccionada. Después de algunos días de asimilación me acostumbré a la idea y creo que sí utilizaría este nuevo operador, aunque solo en ciertos contextos. Sin embargo, como educador, lo más probable es que optaría por no enseñarlo a mis alumnos, al menos no durante un curso de introducción a la programación. La razón es simple: idealmente cada enunciado debe tener un solo efecto. Si un enunciado tiene dos o más efectos resulta más difícil de entender. Es preferible que cada efecto esté en su propia línea. En el último código, la línea 1 tiene dos efectos: la asignación y el resultado de la condición del ciclo. Esta complejidad no la necesita un principiante, y por tanto me parece más conveniente evitarla. Y así es como enseñamos a programar: evitando presentar a nuestros estudiantes aquellos elementos del lenguaje que no contribuyen a lograr nuestros objetivos académicos.

Reflexiones

Antes que todo, pienso que es una pena que Guido haya abandonado su puesto como BDFL. Sin embargo entiendo y respeto completamente su decisión y no puedo mas que sentir un profundo agradecimiento por todo el tiempo y la dedicación que invirtió para lograr lo que actualmente es Python y su vibrante comunidad. También hay que recalcar que Guido no va a esfumarse. De hecho, él continuará presidiendo la Python Software Foundation (PSF), que es la organización dedicada a fomentar el desarrollo de la comunidad de Python. En la biografía de su cuenta de Twitter, Guido ahora se describe como “Creador de Python y BDFL emérito”.

Es válido que la gente esté en desacuerdo con nuestras ideas y es muy valioso que podamos discutir, pero siempre y cuando lo hagamos de manera inteligente y respetuosa. Lamentablemente, en muchas ocasiones lo anterior es la excepción y no la regla. Lo que ocurrió a raíz del PEP 572 es un fenómeno que estamos viendo en otros lados. Al parecer todo el mundo se siente con la libertad de expresar su opinión y ahora, gracias a la Internet y a las redes sociales, tenemos a nuestra disposición un público de un tamaño que jamás nos hubiéramos imaginado tan solo hace algunos años. En principio esto parece algo bueno, ya que podría ser la base para una verdadera democratización, en donde todos pueden hacer oír su voz. Pero lo que ha pasado en muchos casos es que los que hablan y gritan más fuerte son los que han estado dominado el escenario. Muchas personas se sienten con todo el derecho de vociferar su opinión, no importándoles si sus argumentos cuentan o no con un sustento razonable. ¿A caso ser escandaloso tiene más peso que ser instruido?

Fuente: www.vexels.com

Un número desmedido de personas repudiaron la decisión de Guido de aprobar el PEP 572 y se lo manifestaron de manera hiriente. En una entrevista realizada por InfoWorld hace unos días, Guido comentó que sentía que había perdido la confianza de los desarrolladores del núcleo de Python cuando varios de ellos le atacaron de manera personal en redes sociales como Twitter. Al igual que la mayoría de esos desarrolladores, el rol de BDFL que desempeñaba Guido era también a título de voluntario. ¿Qué puede ser más desmoralizante que hacer un trabajo de manera generosa y a cambio de ello recibir severas críticas y agresiones?

Regresemos ahora al tema de las dictaduras benevolentes. Si vivimos en un país democrático muy probablemente consideramos que la democracia es el estilo de gobierno que nos conviene emular en otros entornos de nuestra sociedad. Pero la democracia no funciona en todos los contextos. Imaginemos un hogar conformado por cinco personas: tres hijos pequeños, la mamá y el papá. Si cada mañana deciden entre todos el menú para desayunar de manera democrática existe una alta probabilidad de que acabarán comiendo siempre helado y hot cakes. La verdad es que unos buenos padres procurarán brindar una alimentación balanceada a sus hijos, no porque quieran fastidiarlos dándoles comida que a lo mejor no les gusta, sino porque buscan su bienestar a largo plazo. En otras palabras, los padres juegan el rol de dictadores benevolentes. Unos padres amorosos seguramente escucharán y tomarán en cuenta las opiniones de sus hijos, pero finalmente tomarán decisiones que no siempre serán populares ni bien recibidas.

Fuente: www.shutterstock.com

La comunidad de Python decidió desde sus inicios que su forma de gobierno iba ser a través de un dictador benevolente. La idea era contar con una persona sabia y visionaria que pudiera tomar las decisiones difíciles, cuidando siempre los intereses de la propia comunidad. Ése era el acuerdo. Inicialmente, para cada situación importante, iba a haber un espacio para discutir los diferentes puntos de vista. Pero al final Guido tomaría la última decisión y todos tendrían que acatarla. Guido era el capitán del barco, y se le otorgó a él la confianza y el permiso para dirigir la nave de acuerdo a su criterio. Se estableció desde el principio que esto no iba funcionar como una democracia. Por lo tanto, una vez tomada una decisión por parte del BDFL ya no queda nada más que hacer, salvo apechugar en caso de que no fuera de nuestro agrado. Al parecer no todo el mundo entiende cómo funciona este estilo de gobierno. Después de que Guido anunció su decisión sobre el PEP 572 muchos inconformes sintieron que estaban en su derecho de lanzarse a la yugular del BDFL.

He podido de ver de primera mano que Guido tiene una personalidad conciliadora y no busca imponerse. Esto contrasta con otros BDFLs, como es el caso de Linus Torvalds, quien no tiene problemas en mandar al carajo a quienes no comparten su punto de vista. Incluso Torvalds alguna una vez dijo: “No soy una persona amable, y tú no me interesas. Me importa la tecnología y el núcleo de Linux; eso es lo importante para mí”. Pero Guido no es así. Él es un individuo gentil que busca llevarse bien con la gente y que pone a las personas por encima de la tecnología. Es probable que esa forma afable de ser lo llevaría a ir acumulando a través de los años una enorme presión que finalmente terminaría por reventarlo.

Lo que mucha gente se pregunta ahora es: ¿qué va a pasar con Python? ¿Qué va a ocurrir si se decide que el lenguaje evolucione bajo un esquema en donde mucha gente pueda meter su cuchara? Esto preocupa porque viene a la mente aquel viejo proverbio inglés que dice: “Demasiados cocineros echan a perder el caldo”.

https://d12m9erqbesehq.cloudfront.net/wp-content/uploads/sites/21338/2018/04/12132631/cooking.jpg
Fuente: northwoodelementary.eventsmart.com

En el pasado, algunos lenguajes de programación han sido diseñados y extendidos mediante comités conformados por múltiples compañías e individuos. Ese fue el caso de la estandarización de Common Lisp. Cada miembro del comité tenía su propia visión de lo que consideraba que debía incluir el lenguaje. El problema fue que las visiones individuales no necesariamente coincidían entre sí. Si alguien quería que se incorporara una determinada característica en el lenguaje a menudo tenía que realizar concesiones con los otros miembros del comité. Así pues quedó finalmente un lenguaje gigantesco (la especificación original consistía de más de mil páginas) y chipotudo (con inconsistencias y redundancias). Bien dijo el ingeniero automotriz británico Alec Issigonis (creador del auto Mini original): “un camello es un caballo diseñado por un comité”.

Fuente: medium.com

Otro problema que tienen los comités es que frecuentemente tardan mucho tiempo en generar resultados, sobre todo si el número de integrantes es grande. Podemos observar esta situación en la evolución que ha tenido el lenguaje Java comparada con el lenguaje C#. En el año 1995, Sun Microsystems liberó la primera versión de Java. Por su parte, Microsoft sacó C# al mercado siete años después. Aunque inicialmente C# fue denunciado por muchos como una copia deficiente de Java, al paso de los años esta situación cambió. Java poco a poco se fue rezagando a tal grado que ahora es Java quien le está copiando a C#. Por ejemplo, las funciones anónimas (conocidas también como lambdas) aparecieron en C# 3.0 en 2007, pero fue hasta el 2014 que fueron incorporadas a Java 8. El lenguaje Java tarda más tiempo en avanzar debido a que depende del Proceso de la Comunidad Java (JCP por sus siglas en inglés), que está subordinado a un comité relativamente extenso que se encarga de tomar todas las decisiones relacionadas con la plataforma Java. Por otro lado, el rápido y ágil progreso de C# ha sido producto de un pequeño equipo encabezado por el eminente ingeniero de software danés Anders Hejlsberg (creador de Turbo Pascal, Delphi y C#).

¿Tomará Python el camino de un estilo de gobierno encabezado por un comité? En la entrevista de InfoWorld previamente mencionada, Guido comentó lo siguiente:
El grupo de desarrolladores del núcleo de Python acordó una agenda para llegar a una conclusión. La fecha límite para las propuestas es el 1° de octubre de 2018. Entonces, me parece, que para el 1° de noviembre de 2018 se han comprometido a haber seleccionado una propuesta para una estructura de gobierno. Luego, para el 1° de enero de 2019, se comprometieron a elegir o designar efectivamente, o como sea que se indique en sus documentos de gobierno, a las personas que estarán a cargo.

Si una de las propuestas es que haya un solo BDFL, esa propuesta deberá redactarse detalladamente
para el 1° de octubre, indicando cómo se seleccionará, cuánto tiempo permanecerá a cargo, cómo se le puede impugnar, y todo eso. Tal vez para el 1° de enero tendrán una persona real designada.
En un podcast de PythonBytes, Carol Willing y Brett Cannon, dos de los desarrolladores del núcleo de Python, comentaron cómo creen ellos que va a quedar conformado el nuevo modelo de gobierno para Python. Al parecer se está pensando en que haya un nuevo BDFL, o alternativamente un “consejo de ancianos” compuesto por entre 3 y 5 personas. Esto me parece una muy buena noticia por la razón que ya expuse anteriormente.

Fuente: maxima.id

Haciendo a un lado la dimisión de Guido como BDFL, hay que reconocer que Python está viviendo su mejor momento y dudo que esto vaya a cambiar en el futuro inmediato. Según Stack Overlow, de los principales lenguajes de programación, Python ha sido el que más ha crecido en los últimos cinco años dentro de los países con mayores ingresos. El índice TIOBE de julio de 2018 coloca a Python como el cuarto lenguaje de programación más popular del momento, solo atrás de Java, C y C++. Por otra parte, Python aparece en el primer puesto tanto en el índice de popularidad de lenguajes de programación (PyPL) de julio 2018 como en la clasificación 2018 de los principales lenguajes de programación de la revista IEEE Spectrum.

Una gran parte de la comunidad de Python está conformada por usuarios que no son desarrolladores de software pero que sí necesitan programar para resolver problemas de cómputo científico, ciencia de datos y aprendizaje automático. Estos usuarios dependen de herramientas basadas en Python como Jupyter, NumPy, SciPy, Matplotlib, pandas y TensorFlow. No veo que el retiro de Guido les pudiera afectar, incluso si la evolución del lenguaje se detuviera por algunos años. La inmensa comunidad de Python está muy bien consolidada y eso permitirá que trascienda más allá de una sola persona. Desde luego que vamos a extrañar al buen Guido, nuestro dictador benevolente, pero me siento optimista sobre el destino de Python.

Con Guido, BDFL emérito.
Foto tomada durante PyCon USA, mayo de 2018.

26 de marzo de 2018

Nueva certificación de Microsoft: Introducción a la programación usando Python

Actualización (noviembre de 2018): Unos meses después de que escribí esta entrada del blog tuve la oportunidad de presentar la certificación de PCAP (Certificación de Python a nivel asociado) ofrecida por el Python Institute. También escribí una entada respecto a esta experiencia, la cual complementa de manera relevante la información que se presenta a continuación.

Introducción

Una certificación profesional es un proceso por el cual una organización valida y dictamina el nivel de conocimiento y/o competencia que tiene una persona para un cierto trabajo o tarea. En el área de TI (Tecnologías de Información) las certificaciones profesionales comenzaron a popularizarse en la década de los años noventa a través de diversas empresas como Cisco, Novell, IBM, Oracle y Microsoft. Con ello cualquier individuo tiene, desde entonces, la posibilidad de ganarse las credenciales que avalan su dominio en el manejo de ciertas herramientas tecnológicas demandadas en la industria.

Fuente: www.certifiedeo.com

Hasta hace relativamente poco había tan solo un puñado de certificaciones relacionadas con Python, las cuales se podían obtener después de tomar uno o varios cursos presenciales o en línea (por el ejemplo los cursos ofrecidos por la Universidad de Illinois a través de la O’Reilly School of Technology) o presentando un examen no supervisado por Internet (como los ofrecidos por la empresa Brainbench). Sin embargo, no existía una certificación de Python que tuviera un amplio reconocimiento en la industria a nivel mundial. Por decir, algo equivalente a la certificación de Sun Microsystems/Oracle para el lenguaje Java o la certificación de Ruby ofrecida por la Ruby Association. Al parecer esta situación está cambiando a partir de hace unos meses.


El recién creado Python Institute anunció que está preparando dos certificaciones de tipo vendor-neutral (independientes de proveedor). El primero y más básico es el Python Certified Associate Programmer (PCAP), que será liberado supuestamente en este mismo mes (marzo de 2018). El segundo y más avanzado es el Python Certified Professional Programmer (PCPP), el cual está programado para ofrecerse a partir de julio de 2018. PCAP no tiene requisitos previos, pero, como es de esperarse, para ser PCPP primero se tiene que ser PCAP. Cada una de estas certificaciones se obtendrá pasando un examen supervisado en alguno de los más de cinco mil centros autorizados de evaluación Pearson VUE localizados alrededor del mundo. El costo anunciado de estos dos exámenes es de $295.00 USD, con la posibilidad de obtener un descuento del 50% si se toman los cursos en línea correspondientes, los cuales no tienen costo.

Otra opción para certificarse en Python apareció apenas en agosto de 2017. 98-381 “Introducción a la programación usando Python” es la clave y el nombre del nuevo examen ofrecido por Microsoft. Conviene mencionar que además de esta certificación, Microsoft recientemente ha hecho un esfuerzo encomiable para apoyar al lenguaje Python y a su comunidad. Por ejemplo, Python ahora corre en Visual Studio 2017, Visual Studio Code y el Subsistema de Windows para Linux; así mismo, Azure (el servicio de cómputo en la nube de Microsoft) permite crear Jupyter Notebooks (documentos que contienen código fuente, ecuaciones, visualizaciones y texto explicativo) de forma gratuita.

Fuente: www.microsoft.com

Desde el año 2000 he obtenido más de una decena de certificaciones profesionales, principalmente relacionadas con la plataforma Java. La verdad es que me gusta el desafío que representa obtener una certificación en algún área de mi interés. Así que cuando me enteré de que Microsoft estaba ofreciendo una certificación con Python no pude mas que sentirme intrigado y decidí aceptar el reto.

Meme generado en: imgflip.com

En lo que resta de esta entrada del blog comentaré los detalles más importantes de la nueva certificación de Microsoft así como mi experiencia personal presentando este examen.

Información general sobre el examen

NOTA: La información que se presenta a continuación fue recopilada durante los meses de febrero y marzo de 2018. Algunos datos podrían diferir en el futuro. Recomiendo consultar el sitio oficial de Microsoft para obtener la información actualizada.

El examen 98-381 (Introducción a la programación usando Python) está basado en la versión 3.6 (o superior) de Python y va dirigido en particular al siguiente público:
  • Profesionales de TI
  • Desarrolladores de software
  • Trabajadores de la información (information workers)
El sitio oficial además agrega esto:
Los candidatos a este examen deben poder reconocer y escribir de forma sintácticamente correcta código de Python, reconocer tipos de datos compatibles con Python y poder reconocer y escribir código de Python que resuelva lógicamente un problema concreto.

Se espera que los candidatos hayan tenido, como mínimo, clases y/o experiencia práctica de aproximadamente 100 horas con el lenguaje de programación Python, estén familiarizados con sus funciones y capacidades, y comprendan cómo escribir, depurar y mantener código de Python bien formado y documentado.
Específicamente se evalúan las siguientes habilidades:
  • Realizar operaciones usando tipos de datos y operadores.
  • Controlar el flujo con decisiones y ciclos.
  • Realizar operaciones de entrada y salida.
  • Documentar y estructurar código.
  • Diagnosticar problemas y gestionar errores.
  • Realizar operaciones usando módulos y herramientas.
En mi trabajo como profesor en el Tecnológico de Monterrey he impartido varias veces el curso de Fundamentos de programación usando Python, en el que cubrimos una gran porción de los temas mencionados arriba. Así que la mayor parte del contenido del examen ya lo manejaba bastante bien. Solo tuve que concentrarme en estudiar la parte del API de Python, específicamente los módulo math, datetime, io, sys, os, os.path y random. En total le habré dedicado unas tres o cuatro horas de estudio.

Al acreditar el examen 98-381 se obtiene la certificación MTA (Microsoft Technology Associate). Su costo varía según el país. Para México y otros países de Latinoamérica el costo del examen es de $62.00 USD. En Estados Unidos el examen cuesta $127.00 USD. El costo del examen en España y otros países de la Unión Europea es de €127.00 EUR. El examen se lleva a cabo por computadora y es necesario acudir a un centro de evaluación autorizado de Pearson VUE o Certipoint para presentarlo.

Distintivo (badge) MTA
(Microsoft Technology Associate)

El examen se ofrece en varios idiomas, incluyendo inglés y español. Yo hice mi examen en inglés, pues me inquieta la idea de no poder entender completamente las traducciones que luego se emplean para ciertos términos técnicos. Por ejemplo, en el mismo sitio en español de Microsoft usan la palabra “operarios” como traducción de operators en inglés. Sin embargo, la mayoría de la gente de habla hispana usamos el término “operadores”. De forma similar, yo uso el término “operaciones de rebanadas” como traducción de slicing operations, pero en el sitio de Microsoft le llaman “operaciones de troceado”. No dudo que otros autores traduzcan estos y otros términos de manera muy distinta. Para no tener que estar adivinando, prefiero presentar este tipo de exámenes siempre en inglés.

Fuente: www.trialinteractive.com

El estilo de las preguntas del examen es variado. Hay una serie de videos (en inglés) en los que se muestran todos los posibles tipos de pregunta. A mí principalmente me tocaron preguntas de opción múltiple o de arrastrar y soltar. En total, el examen consta de 40 preguntas, las cuales se deben responder en 45 minutos como máximo. Esto significa que se tiene, en promedio, un poco más de un minuto para responder cada pregunta. Estoy acostumbrado a terminar este tipo de exámenes con bastante tiempo de sobra, incluso alcanzo a repasar con relativa calma todas mis respuestas antes de darlo por terminado. Pero esta vez no fue así. Por primera vez no alcancé a terminar un examen de certificación en el tiempo designado. Me quedé sin poder responder las últimas dos preguntas.

Fuente: naturalsociety.com

Debo confesar que durante la recta final del examen comencé a sentirme agobiado y con dudas sobre mi capacidad para concluirlo de manera exitosa. Afortunadamente, todo salió bien al final. Se requieren 70 de un total de 100 puntos para pasar el examen. En mi caso obtuve 90 puntos, así que logré acreditarlo con bastante holgura, aún a pesar del par de preguntas que me faltaron responder.

El resultado del examen está disponible inmediatamente al terminar, el cual se proporciona en forma de un reporte como el que se muestra a continuación:


El reporte muestra el desempeño de cada una de las seis habilidades evaluadas en el examen usando barras horizontales. El desempeño es mejor entre más larga sea la barra.

Una vez acreditado el examen, el sitio de certificación de Microsoft proporciona la opción de descargar en formato electrónico el certificado correspondiente.

Certificado de MTA

Y a final de cuentas, ¿conviene certificarse?

El tema de las certificaciones en TI puede llegar a ser controvertido. Los detractores de las certificaciones consideran que éstas son solo un negocio para las compañías que las emiten, que no garantizan que alguien realmente domina el material examinado, y que la experiencia práctica obtenida en el trabajo y/o proyectos FOSS (software libre y de código abierto) es mucho más valiosa. A mi parecer estas críticas son bastante válidas, pero hay que considerarlas en su justa dimensión, pues de otra forma podríamos caer en el error de usarlas también en contra de cualquier esquema de educación formal.

El sitio de Microsoft enuncia las siguientes motivaciones para obtener una certificación profesional en el área de TI:
Las certificaciones le proporcionan una ventaja profesional al ser una prueba respaldada y mundialmente reconocida por la industria del dominio de unas habilidades, demostrando su capacidad y voluntad para aceptar las nuevas tecnologías. Verifique sus habilidades, consiga más oportunidades.
Para un joven recién graduado de una carrera profesional, alguien que posiblemente tenga poca o nula experiencia laboral, una certificación puede ser un factor importante para diferenciarse de otros candidatos a un mismo puesto de trabajo. Sin embargo, para alguien que ya tiene varios años de experiencia trabajando en la industria, las certificaciones pueden ser irrelevantes, aunque esto también depende del área de especialidad. Por ejemplo, las certificaciones en el área de seguridad, redes y administración de proyectos son más trascendentes que las del área de programación. El siguiente artículo (en inglés) escrito por Bob Violino hace una reflexión interesante sobre todo este asunto: The real dirt on programming certifications.

Para mí, en lo particular, las certificaciones han sido un medio para el desafío y la superación personal. Con ellas he podido validar y complementar mis habilidades y conocimientos, ya que me han motivado a prepararme en temas particulares que de otra forma difícilmente hubiera revisado por mi cuenta. Considero que las certificaciones han sido una buena inversión de mis recursos.

Fuente: emojiisland.com

22 de abril de 2017

Reconciliando Python 2 y 3

Python 3 fue liberado oficialmente hace más de ocho años. Sin embargo, todavía en el año 2017 existen razones que nos obligan a tener que escribir código para Python 2. Puede ser que necesitemos usar alguna biblioteca o programa preexistente escrito en Python 2. O quizás haya algún servicio en línea para aprender a programar que solo funcione con Python 2, por ejemplo PySchools.com. Tal vez requiramos usar algún servidor remoto de Linux que solamente tenga instalado Python 2, y carecemos de los privilegios de administrador necesarios para instalarle software nuevo. También ocurre que en algunos sitios de programación competitiva sus respectivos jueces en línea solo aceptan soluciones escritas en Python 2, como son los casos de omegaUp y el Caribbean Online Judge (COJ). Sea cual sea la razón, no deja de ser un tanto frustrante tener que estar lidiando con dos versiones del lenguaje.


Como educadores nos surgen varias dudas:
  • ¿Qué versión de Python debemos enseñar a alumnos que están aprendiendo a programar actualmente? 
  • ¿Debemos enseñar Python 2, viendo hacia atrás, privilegiando la compatibilidad con el pasado?
  • ¿Debemos enseñar Python 3, viendo hacia adelante, favoreciendo lo que pueden ser las ideas y prácticas del futuro? 
  • ¿Vale la pena, quizás, enseñar ambas versiones de Python? 
  • ¿Es posible escribir programas que funcionen sin modificaciones en las dos versiones? 
  • Pero para empezar, ¿por qué rayos existen dos versiones rivales de Python?

Un poco de historia

La primera versión pública del lenguaje (Python 0.9.0) apareció en 1991. Las versiones 1.0 y 2.0 fueron liberadas en 1994 y 2000, respectivamente. Para mediados de la década pasada, Guido van Rossum, el autor de Python, consideró que el lenguaje había acumulado, a través de los años, elementos redundantes que iban en contra de la filosofía esencial de Python, la cual establece que: “debe haber una, y de preferencia solamente una, manera obvia de hacer las cosas”. Así pues, Guido decidió que en la siguiente versión mayor de Python (originalmente llamada Python 3000 o Py3K) se eliminaran todos aquellos componentes considerados obsoletos o duplicados con el fin de obtener un lenguaje más limpio y elegante, con una mejor oportunidad de evolucionar positivamente sin tener que cargar con vestigios heredados del pasado. Obviamente, estos cambios provocarían una incompatibilidad con prácticamente todo el código de Python existente en aquel momento. Para facilitar la transición, se decidió que coexistieran durante algún tiempo dos versiones de Python. Así pues, a finales de 2008 teníamos disponibles las versiones 2.6 y 3.0 de Python. Así mismo, se proporcionó la herramienta 2to3 para simplificar la migración de los programas de Python a la nueva versión.

Guido van Rossum

En el año 2010 se liberó Python 2.7, la última versión menor de la rama de Python 2. Originalmente solo iba a ser soportada por cinco años. En otras palabras, se esperaba que para el 2015 todos hubiéramos ya migrado a Python 3. Lamentablemente esto no ocurrió y por eso la fecha de EOL (end of life o fin de vida) de Python 2.7 se extendió hasta el 2020. Esto significa que nos quedan por lo menos tres años en las que las versiones 2 y 3 de Python deberán seguir coexistiendo.

¿Qué hacer?

Yo soy de la opinión de que debemos concentrar nuestros recursos y esfuerzos en enseñar a nuestros alumnos Python 3.x, pues es la versión que tiene un futuro claro. Python 2.7 está actualmente en modo de mantenimiento y en pocos años estará descontinuado. No obstante, cuando veamos que surja la necesidad podemos orientar a nuestros alumnos a que utilicen algunas prácticas relativamente simples que permiten escribir programas que funcionan de manera idéntica tanto en Python 2.7 como en Python 3.x. En lo que resta de esta entrada del blog de EduPython explicaré cómo podemos lograr justamente esto.

Si no sabes qué versión del lenguaje estás utilizando puedes correr el siguiente código desde la consola de Python para averiguarlo:
>>> from sys import version
>>> version
'3.6.0 (default, Jan 13 2017, 00:00:00) \n[GCC 4.8.4]'
En mi experiencia hay cuatro diferencias fundamentales entre Python 2.7 y Python 3.x que pueden generarle algo de ruido a una persona que está aprendiendo a programar:
  • Caracteres especiales
  • Instrucción vs. función print
  • Funciones input y raw_input
  • Operador de división
Hay muchas otras situaciones en donde surgen incompatibilidades, pero con resolver las cuatro anteriores cubrimos las necesidades más comunes de un programador principiante. Para una descripción exhaustiva de cómo escribir código de Python compatible entre las versiones 2 y 3 se puede consultar la siguiente página: Cheat Sheet: Writing Python 2-3 compatible code.

Caracteres especiales

Por omisión, un archivo fuente de Python 2 utiliza el código ASCII como esquema de codificación de caracteres. Bajo este esquema solo podemos usar en nuestros programas las letras del abecedario inglés, los dígitos numéricos y algunos otros símbolos de puntuación. En otras palabras, no podemos usar ciertos símbolos propios del idioma español como son: las vocales con acento agudo u ortográfico (á, é, í, ó, ú, Á, É, Í, Ó, Ú), la letra u con diéresis (ü, Ü), la letra eñe (ñ, Ñ) ni los signos de apertura de interrogación y exclamación (¿, ¡). Si nuestro programa contiene cualquiera de estos caracteres no-ASCII, típicamente dentro de un comentario o en una cadena de caracteres, el intérprete de Python produce un mensaje de error parecido a éste:
SyntaxError: Non-ASCII character '\xc3' in file prueba.py on line 5, but no encoding declared;.
Para evitar este error podemos declarar de manera explícita el esquema de codificación de caracteres que utiliza nuestro archivo fuente de Python. Esto se hace incluyendo un comentario similar al siguiente en la PRIMERA o SEGUNDA línea del archivo (ver el documento PEP 263 para más detalles):
# coding=UTF-8
El formato de transformación de Unicode de 8 bits (UTF-8 por sus siglas en inglés) al que se hace referencia arriba es un esquema de codificación que soporta los caracteres de alfabetos modernos y extintos, sistemas ideográficos y colecciones de símbolos matemáticos, musicales, iconos, etc. Esto significa que podemos usar todos los símbolos del español y muchos más, incluyendo cosas como el signo de euro (€) o los palos de una baraja (♥, ♦, ♣, ♠).

Es importante mencionar que para que todo funcione correctamente el editor que se esté utilizando debe guardar el archivo usando el formato UTF-8 y no algún otro. Esto es algo totalmente transparente para el usuario si se está utilizando un editor diseñado expresamente para Python, como es el caso de IDLE o Spyder. Otros editores pudieran requerir alguna configuración explícita.


Python 3, a diferencia de Python 2, supone por omisión que los archivos fuente utilizan UTF-8 como esquema de codificación de caracteres, por lo que estrictamente es innecesario añadir el comentario “#coding=UTF-8” al inicio del archivo si deseamos usar dicho formato, sin embargo no le hace daño incluirlo y por compatibilidad conviene hacerlo. El documento Unicode HOWTO contiene muchos detalles sobre el uso de Unicode con Python.

Instrucción vs. función print

En Python 2 print es una instrucción mientras que en Python 3 es una función. La implicación más importante es que para invocar una función en Python se necesitan paréntesis pero no es así para una instrucción. Veamos unos ejemplos:
# Usando la instrucción print en Python 2
print 'Existen', 2 ** 10, 'bytes en un kibibyte.'
# Usando la función print en Python 3
print('Existen', 2 ** 10, 'bytes en un kibibyte.')
Al correr ambos códigos en sus respectivas versiones de Python la salida esperada es la misma:
Existen 1024 bytes en un kibibyte.
Sin embargo, si el código de arriba diseñado para Python 3 se corre en Python 2, los paréntesis se interpretan como los delimitadores de una tupla de tres elementos, produciendo una salida que resulta extraña cuando no se sabe lo que está sucediendo:
('Existen', 1024, 'bytes en un kibibyte.')
Por otro lado, si el código de arriba diseñado para Python 2 se intenta correr en Python 3, lo que se obtiene es un error de sintaxis:
  File "ejemplo.py", line 3
    print 'Existen', 2 ** 10, 'bytes en un kibibyte.'
          ^
SyntaxError: Missing parentheses in call to 'print'
Para resolver esta incompatibilidad debemos importar print_function del módulo __future__ al inicio de nuestro programa:
from __future__ import print_function
La instrucción anterior obliga a que print solo pueda usarse como función, independiente de la versión del lenguaje que se esté utilizando, por lo que el siguiente código:
from __future__ import print_function

# Usando print como función en Python 2 y 3
print('Existen', 2 ** 10, 'bytes en un kibibyte.')
produce exactamente la misma salida tanto en Python 2 como en Python 3:
Existen 1024 bytes en un kibibyte.


Al ser función, print tiene el beneficio adicional de que puede recibir varios argumentos de palabra clave:
  • sep: Indica qué cadena se debe utilizar como separador (o delimitador) entre los elementos a imprimir. Por omisión se usa un espacio en blanco (' '). 
  • end: Establece qué cadena se debe utilizar después de haber impreso todos los elementos. Se usa un salto de línea ('\n') en caso de no indicarse.
  • file: Define el archivo en el que se debe realizar la impresión. Si se omite usa la salida estándar (usualmente la pantalla).
El siguiente ejemplo muestra cómo usar todos los argumentos de palabra clave de la función print con la ventaja de que funciona de manera idéntica tanto en Python 2 como en Python 3:
from __future__ import print_function

with open('salida.txt', 'w') as f:
    print(4, 8, 15, sep='-', end='|', file=f)
    print(16, 23, 42, sep='*', end='$', file=f)
El código crea un archivo llamado salida.txt con el siguiente contenido:
4-8-15|16*23*42$

Funciones input y raw_input

Python 2 cuenta con dos funciones que permiten directamente leer datos desde la entrada estándar (usualmente el teclado):
  • raw_input: Facilita al usuario la captura de una línea de texto. Dicha línea es devuelta por la función como una cadena de caracteres pero sin incluir el carácter final de salto de línea ('\n').
  • input: Sirve para que el usuario ingrese una secuencia de caracteres que representan una expresión válida de Python. Dicha expresión es evaluada por el intérprete y el objeto resultante es el valor devuelto por la función.
Ambas funciones reciben un prompt (mensaje de entrada) como argumento opcional.


Python 3 solamente cuenta con la función input, que realmente es equivalente en términos de comportamiento al raw_input de Python 2. Si deseamos tener en Python 3 la misma funcionalidad que el input de Python 2 entonces tenemos que utilizar adicionalmente la función eval tal como se detalla en la siguiente tabla:

Función
de Python 2
Equivalente
en Python 3
x = raw_input('Texto: ') x = input('Texto: ')
x = input('Expresión: ') x = eval(input('Expresión: '))

NOTA: El uso de la función eval se considera un riesgo de seguridad pues permite al usuario inyectar código malicioso que pudiera comprometer la integridad del sistema. En general se recomienda evitar su uso.
Para que nuestro programa funcione igual en ambas versiones de Python debemos importar la función input del módulo builtins usando la siguiente instrucción:
from builtins import input
Después de esta instrucción la función input se comporta siempre como si estuviéramos en Python 3, aún estando en Python 2. No está de más mencionar que para obtener una completa compatibilidad entre versiones es importante que dejemos de usar la función raw_input ya que no está disponible en Python 3.
NOTA: Al parecer la instrucción “from builtins import input” produce un error en varias plataformas corriendo Python 2. El mensaje de error indica que no puede hallar el módulo builtins. Para corregir este problema se necesita ejecutar la siguiente instrucción con permisos de administrador desde una terminal de línea de comando:
pip2 install future
El siguiente código es un programa que usa input y que corre sin cambios en las versiones 2 y 3:
# coding=UTF-8

from __future__ import print_function
from builtins import input

num1 = int(input('Ingresa un número entero: '))
num2 = int(input('Ingresa otro número entero: '))
if num1 == num2:
    print('Ambos números son iguales')
elif num1 > num2:
    print(num1, 'es el número más grande')
else:
    print(num2, 'es el número más grande')
Conviene señalar que para convertir la cadena de caracteres devuelta por la función input a un número podemos utilizar las funciones int o float, dependiendo de si necesitamos un número entero o un número real (de punto flotante). Lo anterior es preferible a usar la función eval, la cual es innecesaria en este contexto y potencialmente peligrosa en la páctica.

Operador de división

El operador de división (/) funciona de manera diferente en las versiones 2 y 3 de Python.
NOTA: En Python el operador de división puede ser sobrecargado por cualquier clase (como es el caso de las clases numéricas complex y Fraction). Así pues, este operador puede tener un comportamiento muy diferente al aquí descrito cuando se usa con objetos que no sean específicamente números enteros o reales.
Veamos algunos ejemplos con Python 2:
# Python 2
>>> 20 / 3
6
>>> 20 / 3.0
6.666666666666667
Aquí podemos ver que al dividir dos números enteros el resultado da un número entero (el cociente de la división sin la parte fraccionaria). Por otro lado, se obtiene un número real cuando al menos uno de los operandos de la división es un número real. Esta forma particular de realizar la división es un legado del lenguaje C que generalmente resulta sorpresivo y poco intuitivo para la gente que está aprendiendo a programar.

La división en Python 3 funciona de manera más predecible:
# Python 3
>>> 20 / 3
6.666666666666667
>>> 20 / 3.0
6.666666666666667
En este caso el operador de división siempre produce un número real como resultado sin importar si sus operandos son enteros o reales. Este comportamiento resulta más accesible para los programadores principiantes.


Para poder usar el operador de división de forma que sea compatible con Python 2 y 3 debemos importar division del módulo __future__:
from __future__ import division
La instrucción anterior garantiza que el operador de división devolverá un resultado real. El siguiente programa produce los mismos resultados en las dos versiones de Python:
# coding=UTF-8

from __future__ import print_function
from __future__ import division

print(1 / 2)   # División verdadera (true division)
print(1 // 2)  # División de piso (floor division)
La salida de este programa es:
0.5
0
El ejemplo anterior muestra también el uso del operador de división de piso (//) el cual calcula el cociente entero de la división.

Resumen de consejos de compatibilidad

Aquí está el resumen de los cuatro consejos discutidos para escribir código fuente compatible con Python 2.7 y Python 3.x:
  • Si necesitas usar caracteres que no son parte del código ASCII (caracteres con tilde, eñe, etc.) en un archivo fuente de Python, entonces guárdalo usando el formato UTF-8 y añádele el siguiente comentario en la primera o segunda línea:
    # coding=UTF-8
    
  • Utiliza print siempre como función y no como instrucción. Añade el siguiente import a tu programa para que así sea:
    from __future__ import print_function
    
  • Para que tu programa lea una cadena de caracteres desde la entrada estándar (típicamente el teclado) utiliza únicamente la función input y solo después de usar el siguiente import:
    from builtins import input
    
    Utiliza las funciones int y float si requieres convertir la cadena de entrada a un valor numérico.
  • Para que el operador de división (/) siempre produzca un resultado real, sin importar si sus operandos son reales o enteros, añade a tu programa el siguiente import:
    from __future__ import division
    
    Utiliza el operador de división de piso (//) si requieres el cociente entero como resultado de dividir un número entre otro.