¿Y si Python permitiera 'end' como fin de bloque? (y III)

El otro día, por razones que no vienen mucho al caso, me pregunté cómo de difícil sería añadir la posibilidad de incorporar ese end como marca de fin de bloque, por mi mismo. Así que me dirigí al repositorio de cPython, el intérprete de Python, y me lo bajé.

Ya en el propio README me encontré un enlace a la referencia de desarrollador de Python, lo que me serviría de guía en el proceso.

Lo primero que me planteé fue una modificación de la gramática. El directorio Grammar/ parecía prometedor, y, efectivamente, allí nos encontramos con python.gram, el archivo que representa a la gramática actual del lenguaje.

Aparecen muchas reglas EBNF, y una de ellas es la que parece más prometedora:

pass_stmt[stmt_ty]:
    | 'pass' { _PyAST_Pass(EXTRA) }

Al fin y al cabo, la forma más sencilla de lograr una marca de fin de bloque, que no implique generación de código, es crear un sinónimo de la palabra clave pass.

pass_stmt[stmt_ty]:
    | 'pass' { _PyAST_Pass(EXTRA) }
    | 'end'  { _PyAST_Pass(EXTRA) }

De acuerdo, ahora falta generar la gramática y compilar. Un vistazo rápido a la guía del desarrollador nos dice que lo que debemos hacer es:

$ make regen-pegen
$ make -j4

Le estamos pidiendo que regenere la gramática, y estamos recompilando cpython con 4 procesos. En Linux, el comando nproc nos dice cuántos procesos se pueden ejecutar concurrentemente. Así que podemos incluso ejecutar `make -j$(nproc)', lo cual automáticamente genera el número máximo de trabajos soportados.

En cualquier caso, nos encontraremos con este mensaje de error:

SyntaxError: invalid syntax (posixpath.py, line 305)

Si nos vamos a esa línea de posixpath.py, nos encontraremos con el uso de end como variable:

$ cat -n Lib/posixpath.py| grep 305
305:        end = b'}'

Esto es un problema. Si curioseamos un poco más, veremos que las variables start/end son bastante populares. Así que nos nos queda más remedio que deshacer el cambio en python.gram, y recompilar.

$ make regen-pegen
$ make -j4

Tiene que haber una forma más sencilla. No puede ser que creemos una nueva característica, que claramente tiene que ser opcional, pero que a la vez esta colisione con código ya existente.

Sabemos que Python tiene un módulo llamado __builtins__ que incorpora funciones y constantes que, por decirlo de alguna manera, siempre están disponibles. Es el caso de print, por poner un ejemplo.

>>> __builtins__
<module 'builtins' (built-in)>
>>> dir(__builtins__)
[
    # (...más cosas...)
    'abs', 'aiter', 'all', 'anext', 'any', 'ascii', 'bin', 'bool', 'breakpoint', 'bytearray', 'bytes', 'callable', 'chr', 'classmethod', 'compile', 'complex', 'copyright', 'credits', 'delattr', 'dict', 'dir', 'divmod', 'end', 'enumerate', 'eval', 'exec', 'exit', 'filter', 'float', 'format', 'frozendict', 'frozenset', 'getattr', 'globals', 'hasattr', 'hash', 'help', 'hex', 'id', 'input', 'int', 'isinstance', 'issubclass', 'iter', 'len', 'license', 'list', 'locals', 'map', 'max', 'memoryview', 'min', 'next', 'object', 'oct', 'open', 'ord', 'pow', 'print', 'property', 'quit', 'range', 'repr', 'reversed', 'round', 'sentinel', 'set', 'setattr', 'slice', 'sorted', 'staticmethod', 'str', 'sum', 'super', 'tuple', 'type', 'vars', 'zip'
]

Si pudiéramos añadir end como una constante en ese módulo, equivalente a ..., pues... ya estaría. El código Python sería:

end = ...

La cuestión es dónde se definen estas funciones, como print, o "..." que es la ellipsis. De hecho, si buscamos con:

$ grep -i "ellipsis" Grammar/python.gram
230:# note below: the ('.' | '...') is necessary because '...' is tokenized as ELLIPSIS
903:    | '...' { _PyAST_Constant(Py_Ellipsis, NULL, EXTRA) }

$ grep -niR "ellipsis" --include "*.c"
(...más cosas...)
Python/bltinmodule.c:3535:    SETBUILTIN("Ellipsis",              Py_Ellipsis);

Entonces nos encontramos con que Ellipsis, que representa a ..., es tokenizado como Py_Ellipsis. Si extendemos la búsqueda a los archivos de extensión .c, nos encontraremos con que hay un archivo llamado bltinmodule.c, que es precisamente el que estamos buscando. Así que justo debajo de la línea 3535, añadimos nuestra nueva definición:

SETBUILTIN("end",              Py_Ellipsis);

Y recompilamos:

$ make -j4

Esto genera el ejecutable python en la raiz. ¡Podemos lanzarlo y probarlo!

$ ./python

Python 3.15.0a8+ (heads/main-dirty:5fcab14c350, May 12 2026, 09:35:43) [GCC 15.2.1 20260209] on linux
Type "help", "copyright", "credits" or "license" for more information.

>>> end
Ellipsis

¡Funciona! Hagamos una prueba (hecho en el propio REPL):

class Entero:
...     def __init__(self, x):
...         self._x = x
...     end
...     @property
...     def x(self):
...         return self._x
...     end
...     def __str__(self):
...         return str(self.x)
...     end
... end
... 
Ellipsis
>>> e1 = Entero(42)
>>> e1.x
42
>>> str(e1)
'42'

Si pasamos este código a un archivo test_end.py:

class Entero:
    def __init__(self, x):
        self._x = x
    end

    @property
    def x(self):
        return self._x
    end

    def __str__(self):
       return str(self.x)
    end
end


if __name__ == "__main__":
    e1 = Entero(42)
    print(e1)
end

Y lo ejecutamos con ./python test_end.py, obtenemos:

42

Y así concluye el viaje. Se puede obtener el comportamiento deseado modificando el módulo __builtins__ de Python. ¡Un interesante ejercicio, al menos!