PEP 686 - UTF-8 como configuración predeterminada

PEP 686 - El modo UTF-8 será el valor predeterminado a partir de Python 3.15

• UTF-8 se está convirtiendo en el estándar de facto para la codificación de texto
  • La codificación predeterminada de los archivos fuente de Python es UTF-8
  • JSON, TOML y YAML usan UTF-8
  • La mayoría de los editores de texto, como Visual Studio Code y el Bloc de notas de Windows, usan UTF-8 de forma predeterminada
  • La mayoría de los sitios web y los datos de texto en Internet usan UTF-8
  • Muchos otros lenguajes de programación populares, como Node.js, Go, Rust y Java, también usan UTF-8 de forma predeterminada
• Cambiar la codificación predeterminada a UTF-8 facilita que Python sea interoperable con otros lenguajes
• Muchos desarrolladores de Python que usan Unix olvidan que la codificación predeterminada varía según la plataforma
  • Al leer archivos de texto codificados en UTF-8 (JSON, TOML, Markdown, archivos fuente de Python, etc.), no especifican encoding="utf-8"
  • La codificación predeterminada inconsistente provoca muchos bugs

Cambios principales de PEP 686

• A partir de Python 3.15, el modo UTF-8 estará habilitado por defecto
  • Los usuarios aún pueden desactivar el modo UTF-8 configurando PYTHONUTF8=0 o -X utf8=0
• Se agrega locale.getencoding()
  • API para obtener la codificación regional independientemente del modo UTF-8
  • Si se especifica la opción warn_default_encoding, locale.getpreferredencoding() generará EncodingWarning, al igual que open() (ver PEP 597)
• Ajuste de la opción encoding="locale"
  • TextIOWrapper debe usar la codificación regional incluso en modo UTF-8 cuando se especifica encoding="locale"

Compatibilidad hacia atrás

• La mayoría de los sistemas Unix usan una configuración regional UTF-8 y Python activa el modo UTF-8 cuando la configuración regional es C o POSIX, por lo que este cambio afectará principalmente a los usuarios de Windows
• Si un programa de Python depende de la codificación predeterminada, este cambio puede provocar UnicodeError, texto corrupto o corrupción silenciosa de datos
• Guía para resolver problemas de compatibilidad hacia atrás:
  1. Desactivar el modo UTF-8
  2. Usar EncodingWarning (PEP 597) para encontrar todos los lugares afectados por el modo UTF-8
     • Si se omite la opción encoding, considerar usar encoding="utf-8" o encoding="locale"
     • Si se usa locale.getpreferredencoding(), considerar usar "utf-8" o locale.getencoding()
  3. Probar la aplicación con el modo UTF-8

Opinión de GN⁺

• Este PEP busca unificar la codificación predeterminada de Python en UTF-8 para mejorar la interoperabilidad con otros lenguajes y sistemas. Esto ayudará a que Python pueda usarse con mayor fluidez en entornos de desarrollo globales
• Sin embargo, este cambio puede afectar la compatibilidad hacia atrás de programas de Python existentes. En particular, se debe tener cuidado con los programas que se ejecutan en entornos Windows
• Los desarrolladores deben usar EncodingWarning para identificar las partes afectadas y responder especificando explícitamente la opción encoding, entre otros métodos
• A largo plazo, se espera que este cambio tenga un impacto positivo en el ecosistema de Python. Sin embargo, a corto plazo puede generar costos de migración en algunos proyectos
• Los desarrolladores deben tener en cuenta este cambio al planear la actualización a Python 3.15 y, si es necesario, tomar medidas adecuadas para mantener la compatibilidad hacia atrás

[GN⁺]

Opiniones de Hacker News

• El hecho de que la codificación predeterminada de archivos de texto en Python varíe según la plataforma ha sido un problema desde hace mucho tiempo
• El problema de la codificación del sistema de archivos es aparte y no se aborda con este cambio
• No es buena idea depender del valor predeterminado del sistema, porque puede ser distinto a lo que se asume
• En el pasado hubo problemas con Ubuntu y los scripts de init.d. Los scripts de ejecución de Java que corrían como root usaban una codificación distinta a la de los usuarios normales, lo que causaba problemas
• Hoy en día es menos problemático, pero hay que evitar dejar esto en manos del SO. Si se usa una codificación distinta de UTF-8, probablemente no sea intencional
• No es buena idea no especificarlo explícitamente y depender de la configuración del SO
• Este cambio va en la dirección correcta. El código que se rompa es mejor arreglarlo de forma simple
• Me parece mejor que dejarlo en un estado con posibilidad de errores de corrupción de contenido

Regla empírica que se ha vuelto cada vez más cierta en las últimas décadas: si la configuración de "charset" no es UTF-8, está mal

• Python 2 siempre funcionaba bien porque no estaba atado al charset, pero las mejoras de Python 3 fueron más que una simple mejora

• Cómo distinguir un script de Python 3 de uno de Python 2:

  • Si tiene la cadena "utf-8", es Python 3
  • Si solo funciona en la locale C.UTF-8, es Python 3

• Este cambio es bienvenido y parece que va a "mejorar" Python 3

• Pensaba que esto ya era el valor predeterminado desde Python 3

Muchos lenguajes populares, incluidos Node.js, Go, Rust y Java, usan UTF-8 de forma predeterminada

• No sabía que Java se había pasado de UTF-16 a UTF-8

• No sé si la codificación interna de CPython sea UTF-8

• Las cadenas de Python se pueden indexar, pero el acceso aleatorio es poco frecuente, así que quizá convenga hacer indexación diferida cuando haga falta

• Si solo se mueve una posición hacia adelante o hacia atrás, no hace falta un índice

• Por lo tanto, parece posible una representación interna en UTF-8

• ¿Por qué no utf-8-sig? Es útil porque maneja opcionalmente el BOM

• Hablando de UTF-8, el framebuffer de Linux debería haber tenido soporte adecuado para UTF-8 desde hace mucho tiempo

• GNU Hurd ya tenía una mejor "terminal console" con soporte para UTF-8 desde alrededor de 2007

• Increíble que un cambio así llegue recién en 2024

• Buen cambio. Ahora solo falta que JS se pase a UTF-8, pero como tiene que ser compatible con código escrito en 1995, es difícil mejorarlo

Muchos desarrolladores de Python en Unix olvidan que la codificación predeterminada varía entre plataformas y no especifican encoding="utf-8" al leer archivos de texto UTF-8

• Más que "olvidarlo", parece que no lo tienen realmente presente
• Yo pensaba que Python usaría UTF-8 en todas partes, a menos que se pidiera explícitamente otra cosa