¿Es siempre cortés poner código en un archivo de configuración de python?

Question

Una de mis características favoritas sobre python es que puedes escribir archivos de configuración en python que son muy fáciles de leer y entender. Si pone límites a sí mismo, puede estar seguro de que los no pythonistas sabrán exactamente lo que usted quiere decir y serán perfectamente capaces de reconfigurar su programa.

Mi pregunta es, ¿cuáles son exactamente esos límites? Mi propia heurística personal fue

1. Evite el control de flujo. Sin funciones, bucles o condicionales. Esos no estarían en un archivo de configuración de texto y la gente no espera haberlos entendido. En general, probablemente no debería importar el orden en que se ejecutan sus declaraciones.
2. Se adhieren a las asignaciones literales. Los métodos y las funciones que se invocan sobre los objetos son más difíciles de analizar. Cualquier cosa implícita va a ser un desastre. Si hay algo complicado que tiene que suceder con sus parámetros, cambie la forma en que se interpretan.
3. Las palabras clave de idioma y el manejo de errores son correctos.

Supongo que pregunto esto porque me encontré con una situación con mi archivo de configuración Django donde parece ser útil romper estas reglas. Me gusta, pero me siento un poco culpable. Básicamente, mi proyecto se implementa a través de comprobaciones de svn en un par de servidores diferentes que no se configurarán del mismo modo (algunos compartirán una base de datos, otros no, por ejemplo). Así, lanzo un gancho al final:

try: 
    from settings_overrides import * 
    LOCALIZED = True 
except ImportError: 
    LOCALIZED = False 

donde settings_overrides está en el camino de pitón pero fuera de la copia de trabajo. ¿Qué opinas sobre este ejemplo o sobre los límites de configuración de python en general?

Answer 1

Hay una página wiki de Django, que trata exactamente lo que estás preguntando. http://code.djangoproject.com/wiki/SplitSettings

No reinventar la rueda. Use configparser y archivos INI. Los archivos Python son fáciles de descifrar por alguien que no conoce Python.

Answer 2

Su heurística es buena. Las reglas se establecen de modo que los límites se establecen y solo se rompen cuando es obviamente una solución mucho mejor que la alternativa.

Aún así, no puedo evitar elucidar que el código de comprobación del sitio debe estar en el analizador, y se agregó un elemento de configuración adicional que selecciona qué opción se debe tomar.

No creo que en este caso la alternativa es tan mala que romper las reglas tiene sentido ...

-Adam

Answer 3

creo que es un dolor vs argumento placer.

No es incorrecto poner el código en un archivo de configuración de Python porque es todo válido Python, pero significa que podría confundir a un usuario que entra para reconfigurar una aplicación. Si está preocupado por eso, guárdelo con comentarios explicando aproximadamente lo que hace y que el usuario no debe editarlo, en lugar de eso edite el archivo settings_overrides.py.

En cuanto a su ejemplo, está cerca de essential para que los desarrolladores prueben y luego implementen sus aplicaciones. Definitivamente más placer que dolor.Pero realmente debería hacer esto en su lugar:

LOCALIZED = False 

try: 
    from settings_overrides import * 
except ImportError: 
    pass 

Y en su archivo settings_overrides.py:

LOCALIZED = True 

... Si nada más que dejar en claro lo que hace que el archivo .. Lo que estás hacer allí divide las anulaciones en dos lugares.

Answer 4

Como práctica general, vea las otras respuestas en la página; todo depende. Específicamente para Django, sin embargo, no veo nada fundamentalmente malo con la escritura de código en el archivo settings.py ... después de todo, el archivo de configuración es el código :-)

El Django docs on settings themselves dicen:

A ajustes file es solo un módulo de Python con variables a nivel de módulo.

Y dar el ejemplo:

assign settings dynamically using normal Python syntax. For example: 
MY_SETTING = [str(i) for i in range(30)] 

Answer 5

Ajustes como el código es también un riesgo para la seguridad. Usted importa su "configuración", pero en realidad está ejecutando el código que está en ese archivo. Coloque la configuración en los archivos que analiza primero y puede rechazar los valores sin sentido o maliciosos, incluso si le resulta más útil. I blogged sobre esto en diciembre de 2008.