Flacon ('application') contre Flacon (__ nom__)
Dans l'officiel Quickstart , il est recommandé d'utiliser __name__ lors de l'utilisation d'un seul module :
- ... Si vous utilisez un seul module (comme dans cet exemple), vous devez utiliser
__name__car selon qu'il est démarré en tant qu'application ou importé en tant que module, le nom sera différent ('__main__'par rapport au nom d'importation réel). ...
Cependant, dans leur document API , le codage en dur est recommandé lorsque mon application est un package :
C'est donc important ce que vous y fournissez. Si vous utilisez un seul module,
__name__est toujours la valeur correcte. Si toutefois vous utilisez un package, il est généralement recommandé d'y coder en dur le nom de votre package.
Je peux comprendre pourquoi il est préférable de coder en dur le nom de mon package, mais pourquoi ne pas coder en dur le nom d'un seul module? Ou, en d'autres termes, quelles informations peut Flask obtenir lorsqu'il reçoit un __main__ comme premier paramètre? Je ne vois pas comment cela peut faciliter la tâche de Flask pour trouver les ressources ...
__name__ n'est qu'un moyen pratique d'obtenir le nom d'importation de l'endroit où l'application est définie. Flask utilise le nom d'importation pour savoir où rechercher les ressources, les modèles, les fichiers statiques, le dossier d'instance, etc. Lorsque vous utilisez un package, si vous définissez votre application dans __init__.py puis le __name__ indiquera toujours l'emplacement "correct" par rapport à l'emplacement des ressources. Cependant, si vous le définissez ailleurs, comme mypackage/app.py, puis en utilisant __name__ dirait Flask pour rechercher des ressources par rapport à mypackage.app au lieu de mypackage.
En utilisant __name__ n'est pas orthogonal au "hardcoding", c'est juste un raccourci pour utiliser le nom du paquet. Et il n'y a également aucune raison de dire que le nom devrait être le package de base, cela dépend entièrement de la structure de votre projet.
Référence: https://flask.palletsprojects.com/en/1.1.x/api/#flask.Flask
L'objet flask implémente une application WSGI et agit en tant qu'objet central. On lui passe le nom du module ou du package de l'application. Une fois créé, il agira comme un registre central pour le afficher les fonctions, les règles d'URL, la configuration du modèle et bien plus encore.
Le nom du package est utilisé pour résoudre les ressources de l'intérieur du package ou du dossier dans lequel le module est contenu, selon que le paramètre du package se résout en un véritable package python (un dossier avec un __init__.py fichier à l'intérieur) ou un module standard (juste un fichier .py).
Habituellement, vous créez une instance Flask dans votre module principal ou dans le __init__.py fichier de votre package comme ceci:
from flask import Flask
app = Flask(__name__)
L'idée du premier paramètre est de donner à Flask une idée de ce qui appartient à votre application. Ce nom est utilisé pour trouver des ressources sur le système de fichiers, peut être utilisé par des extensions pour améliorer les informations de débogage et un beaucoup plus.
C'est donc important ce que vous y fournissez. Si vous utilisez un seul module, __name__ est toujours la valeur correcte. Si toutefois vous utilisez un package, il est généralement recommandé d'y coder en dur le nom de votre package.
Par exemple, si votre application est définie dans votre application/app.py, vous devez la créer avec l'une des deux versions ci-dessous:
app = Flask('yourapplication')
app = Flask(__name__.split('.')[0])
Pourquoi donc? L'application fonctionnera même avec __name__, grâce à la recherche des ressources. Cependant, cela rendra le débogage plus douloureux. Certaines extensions peuvent émettre des hypothèses en fonction du nom d'importation de votre application. Par exemple, l'extension Flask-SQLAlchemy recherchera dans votre application le code qui a déclenché une requête SQL en mode débogage. Si le nom d'importation n'est pas correctement configuré, ces informations de débogage sont perdues. (Par exemple, il ne reprendrait que les requêtes SQL dans yourapplication.app et non yourapplication.views.frontend)