¿Cuál es la mejor estructura de proyecto para una aplicación Python?

Te damos la bienvenida a nuestra página web, en este sitio vas a encontrar la resolución que estás buscando.

Solución:

No importa demasiado. Lo que sea que te haga feliz funcionará. No hay muchas reglas tontas porque los proyectos de Python pueden ser simples.

• /scripts o /bin para ese tipo de cosas de la interfaz de línea de comandos
• /tests para tus pruebas
• /lib para sus bibliotecas de lenguaje C
• /doc para la mayoría de la documentación
• /apidoc para los documentos API generados por Epydoc.

Y el directorio de nivel superior puede contener README’s, Config’s y otras cosas.

La elección difícil es si utilizar o no un /src árbol. Python no tiene una distinción entre /src, /liby /bin como Java o C tiene.

Desde un nivel superior /src Algunos consideran que el directorio no tiene sentido, su directorio de nivel superior puede ser la arquitectura de nivel superior de su aplicación.

• /foo
• /bar
• /baz

Recomiendo poner todo esto en el directorio “nombre de mi producto”. Entonces, si está escribiendo una aplicación llamada quuxel directorio que contiene todo este material se llama /quux.

Otro proyecto PYTHONPATHentonces, puede incluir /path/to/quux/foo para reutilizar el QUUX.foo módulo.

En mi caso, dado que uso Komodo Edit, mi cuft IDE es un solo archivo .KPF. De hecho, puse eso en el nivel superior /quux y omita agregarlo a SVN.

Según la estructura del sistema de archivos de un proyecto de Python de Jean-Paul Calderone:

Project/
|-- bin/
|   |-- project
|
|-- project/
|   |-- test/
|   |   |-- __init__.py
|   |   |-- test_main.py
|   |   
|   |-- __init__.py
|   |-- main.py
|
|-- setup.py
|-- README

Esta publicación de blog de Jean-Paul Calderone se suele dar como respuesta en #python en Freenode.

Estructura del sistema de archivos de un proyecto de Python

Hacer:

• nombra el directorio algo relacionado con tu proyecto. Por ejemplo, si su proyecto se llama “Twisted”, nombre el directorio de nivel superior para sus archivos de origen Twisted. Cuando haga lanzamientos, debe incluir un sufijo de número de versión: Twisted-2.5.
• crear un directorio Twisted/bin y ponga sus ejecutables allí, si tiene alguno. no les des un .py extensión, incluso si son archivos fuente de Python. No coloque ningún código en ellos, excepto una importación y una llamada a una función principal definida en algún otro lugar de sus proyectos. (Pequeña arruga: dado que en Windows, el intérprete se selecciona por la extensión del archivo, los usuarios de Windows en realidad quieren la extensión .py. Por lo tanto, cuando empaque para Windows, es posible que desee agregarlo. Desafortunadamente, no hay un truco fácil de distutils que Sé cómo automatizar este proceso. Teniendo en cuenta que en POSIX la extensión .py es solo una verruga, mientras que en Windows la falta es un error real, si su base de usuarios incluye usuarios de Windows, es posible que desee optar por tener solo el .py extensión en todas partes.)
• Si su proyecto se puede expresar como un único archivo fuente de Python, colóquelo en el directorio y asígnele un nombre relacionado con su proyecto. Por ejemplo, Twisted/twisted.py. Si necesita varios archivos de origen, cree un paquete en su lugar (Twisted/twisted/con un vacío Twisted/twisted/__init__.py) y coloque sus archivos fuente en él. Por ejemplo, Twisted/twisted/internet.py.
• coloque sus pruebas unitarias en un subpaquete de su paquete (nota: esto significa que la opción de archivo fuente único de Python anterior fue un truco: usted siempre necesita al menos otro archivo para sus pruebas unitarias). Por ejemplo, Twisted/twisted/test/. Por supuesto, que sea un paquete con Twisted/twisted/test/__init__.py. Coloque las pruebas en archivos como Twisted/twisted/test/test_internet.py.
• agregar Twisted/README y Twisted/setup.py para explicar e instalar su software, respectivamente, si se siente bien.

No:

• ponga su fuente en un directorio llamado src o lib. Esto hace que sea difícil de ejecutar sin instalar.
• ponga sus pruebas fuera de su paquete de Python. Esto hace que sea difícil ejecutar las pruebas contra una versión instalada.
• crear un paquete que solamente tiene un __init__.py y luego poner todo su código en __init__.py. Simplemente haga un módulo en lugar de un paquete, es más simple.
• intente crear trucos mágicos para que Python pueda importar su módulo o paquete sin que el usuario agregue el directorio que lo contiene a su ruta de importación (ya sea a través de PYTHONPATH o algún otro mecanismo). Vas a no maneje correctamente todos los casos y los usuarios se enfadarán con usted cuando su software no funcione en su entorno.

valoraciones y reseñas

Puedes corroborar nuestra tarea añadiendo un comentario o puntuándolo te damos la bienvenida.

---

---

Utiliza Nuestro Buscador