En esta lección he mantenido algunas explicaciones que ya no son necesarias actualmente.
Antes de la versión 2.6.0 de Pylint (publicada en marzo de 2021), el formateador black entraba en conflicto con el validador pylint con el sangrado de las condiciones en una sentencia if como el del ejemplo siguiente:
a = 5
b = 7
c = 10
if (
c > a
and c > b
):
print("c es mayor que a y que b")
else:
print("c no es mayor que a y que b")
En este ejemplo, las líneas de la condición (líneas 4 y 5) tienen el mismo sangrado que los bloques de instrucciones (líneas 8 y 10). Este sangrado uniforme es el que aplica black, pero pylint indicaba un aviso "Wrong hanging indentation before block (add 4 spaces). pylint(bad-continuation)"
pylint prefería que la condición tenga más sangrado que los bloques de instrucciones, como en el ejemplo siguiente:
a = 5
b = 7
c = 10
if (
c > a
and c > b
):
print("c es mayor que a y que b")
else:
print("c no es mayor que a y que b")
Ambos sangrados son sintácticamente válidos y siguen las reglas de formato de Python (Pep 8, pero el problema es que cada vez que formateabamos con black el segundo programa, black lo dejaba como el primero y pylint mostraba un aviso (en realidad, mostraba varias veces el mismo aviso, uno por línea).
Se pidió tanto a black como a pylint que resolvieran esta situación (pylint issue #289 y black issue #48), y finalmente fue pylint el que dio su brazo a torcer (punto 2 de la lista de novedades en pylint 2.6.0).
En el curso 2019-20, la única solución que encontré fue desactivar el aviso C0330 de pylint en el archivo de configuración de VSCode.
//
// Extensión pylint (configuración para ejercicios pygame)
"python.linting.pylintArgs": [
"--extension-pkg-whitelist=pygame",
"--disable=C0103, C0114, C0115, C0116, C0330",
// Pylint features. Pylint global options and switches
// https://pylint.pycqa.org/en/2.4/technical_reference/features.html
// http://pylint.pycqa.org/en/latest/technical_reference/features.html
// C0103: invalid-name - Used when the name doesn't conform to naming rules associated to its type (constant, variable, class...).
// C0114: missing-module-docstring - Used when a module has no docstring.Empty modules do not require a docstring.
// C0115: missing-class-docstring - Used when a class has no docstring.Even an empty class must have a docstring.
// C0116: missing-function-docstring - Used when a function or method has no docstring.Some special methods like __init__ do not require a docstring.
// C0330: bad-continuation - Wrong %s indentation%s%s. TODO
],
//
//
En pylint 2.6.0 (publicado el 28/03/2021) eliminaron los avisos bad-continuation C0330 y bad-whitespace C0326, por lo que esté problema desapareció.
La transición de Python 2 a Python 3 resultó mucho más costosa de lo esperado, debido a que Python 3 introdujo muchos cambios en el lenguaje y obligaba a reescribir prácticamente todos los programas (aunque se han creado herramientas para ayudar en ese proceso).
La intención inicial era haber terminado Python 2 con la versión 2.6, pero en 2010 se tuvo que publicar la versión 2.7, incorporando parte de las novedades de Python 3. Además, el período de mantenimiento de Python 2.7 se tuvo que duplicar de los cinco años habituales a diez, hasta 2020.
Un primer obstáculo en el proceso de transición de Python 2 a Python 3 fue la propia disponibilidad de Python 3 en las distribuciones GNU/Linux. Muchas herramientas internas de las distribuciones están escritas en Python y su conversión de Python 2 a Python 3 no era fácil, por lo que las distribuciones no podían pasar simplemente de incluir una versión a otra.
Hasta 2015, Python 2 siguió siendo la versión predeterminada de Python en la mayoría de distribuciones GNU/Linux (aunque se podía instalar Python 3 sin problemas en ellas). Felizmente, esta situación está resuelta en las principales distribuciones:
Aunque las nuevas versiones de las distribuciones se basan en Python 3, las distribuciones basadas en Python 2 seguirán instaladas en servidores durante bastantes años. Ese es el motivo por el que la fundación Python prolongó el período de publicación de actualizaciones de seguridad de Python 2.7 hasta finales de 2019. A partir de 2020 son las distribuciones las que mantienen Python 2.7 durante el tiempo que se mantengan las propias distribuciones (por ejemplo, RedHat 7 se mantendrá hasta el año 2024, como mínimo, y RedHat 8 o Debian 10 todavía permiten instalar Python 2.7).
Un segundo obstáculo en el proceso de transición de Python 2 a Python 3 (y que ha afectado además a todos los sistemas operativos) ha sido la disponibilidad de las bibliotecas.
Python cuenta con un gran número de bibliotecas, cuyo repositorio oficial es PyPI (Python Package Index), que facilitan la programación de aplicaciones complejas. Cuando se publicó Python 3, la inmensa mayoría de bibliotecas sólo estaban disponibles para Python 2 y, lógicamente, si un programa necesitaba alguna biblioteca que sólo estaba disponible para Python 2, el programa no se podía pasar tampoco a Python 3.
Poco a poco, la mayoría de bibliotecas de Python fueron publicando versiones para Python 3, por lo que este problema también está resuelto. Las bibliotecas que no han hecho la transición a Python 3 es normalmente porque están abandonadas.
En marzo de 2016, un estudio de empleados de Microsoft señalaba que por aquel entonces algo más del 50% de las bibliotecas estaban disponibles tanto para Python 2 como para Python 3, un 25% estaban disponibles sólo para Python 2 y un poco menos del 25% estaban disponibles sólo para Python 3, pero la tendencia parecía indicar que a mediados de 2016 Python 3 pasaría a ser la versión más popular.
Varias páginas web hacen un seguimiento de la compatibilidad con Python 3 de las bibliotecas más populares
En julio de 2018, Guido van Rossum anunció su retirada como BDOF.
En diciembre de 2018 se aprobó el PEP 8016 -- The Steering Council Model que establece como modelo de gobernanza de Python un consejo directivo formado por cinco miembros elegidos entre los desarrolladores de Python y que será renovado tras cada publicación de una versión principal de Python. El primer consejo directivo se eligió en enero de 2019 [artículo en lwn.net 04/02/2019]. El segundo consejo directivo se eligió en diciembre de 2019 [PEP 8101].
Guido van Rossum formó parte del primer consejo directivo, pero no del segundo, completando así su retirada de la dirección de Python.
En noviembre de 2020, Guido van Rossum anunció que se incoporaba a la Developer Division de Microsoft para trabajar en temas relacionados con Python. En mayo de 2021 anunció que centraría su trabajo en la mejora del rendimiento de Python.
Referencias: