¿Dónde deberían las funciones de utilidad vivir en Django?

¿Dónde deberían las funciones de utilidad vivir en Django? Funciones como el cifrado / descifrado personalizado de un número, el envío de tweets, el envío de correo electrónico, la verificación de la propiedad del objeto, la validación de entrada personalizada, etc. Cosas repetitivas y personalizadas que uso en varios lugares de mi aplicación. Definitivamente estoy rompiendo SECO ahora mismo.

Vi algunas demostraciones donde las funciones estaban definidas en models.py, aunque eso no me parecía conceptualmente correcto. ¿Deberían ir en una aplicación de “utilidades” que se importa a mi proyecto? Si es así, ¿a dónde van en la aplicación de utilidades? El archivo models.py allí?

Gracias por ayudar a este n00b a salir.

ACTUALIZACIÓN: Déjame ser aún más específico. Digamos que necesito una función “light_encrypt (número)” que toma el parámetro “número”, lo multiplica por 7, agrega 10 y devuelve el resultado, y otra función “light_decrypt (encr_number) que toma el parámetro” encr_number “, resta 10, divide por 7 y devuelve los resultados. ¿En qué lugar de mi árbol de Django pondré esto? Esto no es middleware, ¿no? Como sugiere Felix, ¿creo un paquete de python y lo importo a la vista donde necesito estas funciones?

Pregunta diferente pero la misma respuesta:

Mi diseño habitual para un sitio de django es:

projects/ templates/ common/ local/ 

Dónde:

  • proyectos contiene su proyecto principal y cualquier otro
  • common contiene elementos que puede compartir entre sitios, o al menos no son específicos del proyecto, como si necesita descargar django-profile y django-registration en lugar de tenerlos directamente en python / site-packages
  • plantillas contiene solo eso
  • local contiene elementos que van a ser específicos de la máquina actual, de modo que puede tener datos separados de manera adecuada, como la ubicación de la base de datos y la contraseña. Luego, vinculo las versiones específicas de la máquina (por ejemplo, “machine1-localconfig.py”) para local / localconfig.py y luego puede “importar localconfig” en settings.py
  • Generalmente pongo middleware que es específico de proyecto dentro de un proyecto, y middleware que no es específico de proyecto en común / middleware /
  • asegúrese de agregar el directorio de plantillas al lugar correcto en la configuración (o probablemente, localconfig.py y luego importarlo en la configuración), y asegúrese de agregar los proyectos, directorios comunes y locales a su PYTHONPATH.

Bien, después de leer los comentarios y las respuestas aquí, decidí crear un directorio llamado “common / util /” dentro de mi directorio de proyectos. Dentro de eso tengo un archivo “__ init__.py” donde tengo mis pequeñas funciones de ayuda.

Supongo que si el archivo es demasiado grande, luego dividiré las funciones en archivos .py individuales en común. Así que ahora, mi estructura de proyecto se ve así. Por favor, corríjalo si estoy tomando una mala decisión. Estoy en desarrollo lo suficientemente temprano para poder solucionarlo ahora, ¡aunque todavía es fácil hacerlo!

 myproject/ (Django project) common/ util/ __init__.py (helper functions) middleware/ (custom middleware) templates/ (project templates) myapp/ fixtures/ (initial data to load) migrations/ (south migrations) urls/ views/ admin.py forms.py models.py test.py public/ (static stuff not served by Django) media/ css/ img/ js/ lib/ 

Aquí hay otra forma de hacerlo:

Si las funciones de la utilidad pueden ser un módulo independiente y está utilizando un entorno virtualenv para su aplicación django, puede agrupar la funcionalidad como un paquete e instalarla en su virtualenv.

Esto facilita la importación donde sea que la necesite en su aplicación django.