Generación automática de código se hace comúnmente en las siguientes maneras:
- declaraciones de impresión que contiene fragmentos de código
- plantillas de texto con marcadores de posición (macros creo)
En mi humilde opinión, una mejor práctica es:
- construyó un AST para el fragmento diana, y luego prettyprint
Casi nadie hace esto último, ya que las herramientas son en su mayoría no existe.
La herramienta 2to3 de Python proporciona (creo) el objetivo AST y la impresión bonita.
Pero una pregunta que no hizo, ¿es "generar desde qué?" De alguna manera, debe especificar de forma abstracta lo que desea generar (o no es una ganancia). Y tu herramienta tiene que poder leer esa especificación de alguna manera.
Muchos esquemas de generación de código consisten en escribir código de procedimiento que llama a los mecanismos de generación anteriores; el código de procedimiento actúa como una especificación implícita. Es "fácil" leer la especificación; es solo código en el lenguaje utilizado por el generador de código.
Algunos esquemas de generación de código utilizan algún tipo de estructura de gráfico para proporcionar un marco en el que se cuelgan los fragmentos de especificación, que dirigen la generación de código. Los diagramas de clase UML son un ejemplo clásico. Estos esquemas no son tan fáciles; necesita un "lector de especificaciones" (p., Lector de diagramas UML aka XMI o algo así, o si no está utilizando UML, algún tipo de analizador de especificación).
La herramienta Python 2to3 usa un analizador Python2 para leer la "especificación". Si desea generar código desde Python2, eso estará bien. Sospecho que no quieres hacer eso.
Un enfoque mejor es uno que unifica la capacidad de leer/analizar las especificaciones/poligonal, con la capacidad de producir AST para el idioma de destino.
Nuestro DMS Software Reengineering Toolkit es un sistema de análisis y transformación de programas de propósito general. Analiza "especificaciones" (instancias de gramáticas que puede definir) en AST; también le permitirá construir AST arbitrarios para cualquiera de esas gramáticas, utilizando ya sea código de procedimiento [como se bosquejó anteriormente] o usando patrón-coincidencia/reemplazo (prácticamente exclusivo de DMS). Parte de un front end de DMS es una impresora bonita, que puede regenerar texto de ASTs (estos son probados por el código de ida y vuelta: parse a AST, prettyprint AST, mejor sea el mismo texto).
En caso de que su gramática no se conoce a DMS, que tiene muy buena analizador y generadores prettyprinter, así como otros mecanismos de apoyo para el análisis de los programas. Toda esa maquinaria adicional generalmente no está disponible con los generadores de analizadores clásicos, o con un simple paquete "AST". (No sé qué es 2to3).
La relevancia de esto para Python es que DMS tiene un Python front end y grammars for many other languages.
Por lo tanto, puede analizar su especificación y generar el código de Python utilizando AST seguidos de impresión bonita.
¿Está utilizando un AST personalizado o está creando un Python AST (utilizando, por ejemplo, el módulo 'ast')? –
Lo más probable es que Python AST, utilizando el módulo 'ast'. Me di cuenta de que ANTLR ha atendido un poco a Python, y eso parece un posible camino a seguir, pero parece más sensato quedarse con las partes internas de Python. – mvanveen