Pourquoi affirmer n'est pas largement utilisé?
J'ai trouvé que la déclaration d'assertion de Python est un bon moyen de détecter des situations qui ne devrait jamais se produire . Et il peut être supprimé par optimisation Python lorsque le code est approuvé pour être correct.
Cela semble être un mécanisme parfait pour exécuter des applications Python en mode débogage. Mais en regardant plusieurs projets Python comme Django, twisted et zope, la variable assert n’est presque jamais utilisée. Alors, pourquoi cela se produit-il?
Pourquoi les assertions ne sont-elles pas fréquemment utilisées dans la communauté Python?
Je suppose que la raison principale pour laquelle assert n'est pas utilisé plus souvent est que personne n'utilise le mode "optimisé" de Python .
Les assertions sont un excellent outil pour détecter les erreurs de programmation, pour vous protéger des situations inattendues, mais toute cette vérification d'erreur a un coût. Dans les langages compilés tels que C/C++, cela n'a pas vraiment d'importance, car les assertions ne sont activées que dans les versions de débogage et sont complètement supprimées des versions publiées.
En revanche, en Python, il n’ya pas de distinction stricte entre debug et release mode. L'interpréteur comporte un "indicateur d'optimisation" (-O), mais cela n'optimise pas réellement le code d'octet, mais supprime uniquement les assertions.
Par conséquent, la plupart des utilisateurs de Python ignorent simplement l'indicateur -O et exécutent leurs scripts en "mode normal", qui est kind of le mode débogage, car les assertions sont activées et __debug__ est True, mais est considéré comme "prêt pour la production".
Peut-être serait-il plus sage de changer de logique, c'est-à-dire "optimiser" par défaut et n'activer que les assertions dans un mode de débogage explicite (*), mais je suppose que cela dérouterait beaucoup d'utilisateurs et je doute que nous verrions jamais un tel changement .
((*) C’est par exemple comment le Java VM le fait en proposant un commutateur -ea (enable assertions).)
Plusieurs raisons me viennent à l’esprit ...
Ce n'est pas une fonction principale
Beaucoup de programmeurs, ne nous laissons pas embarrasser par la logique, manquent de respect à tout ce qui ne participe pas directement à l’avant-dernière fonctionnalité du programme. La déclaration assert est destinée au débogage et aux tests et constitue donc un luxe qu’ils peuvent difficilement se permettre.
Tests unitaires
La déclaration d'affirmation est antérieure à la montée et à la montée des tests unitaires. Bien que l’affirmation assert ait encore des utilisations, les tests unitaires sont maintenant largement utilisés pour la construction d’un environnement hostile permettant de dissiper les pièges d’un sous-programme et de son système. Dans ces conditions, les déclarations commencent à ressembler à des couteaux dans une fusillade.
Amélioration du respect des tests par l'industrie
La déclaration d'affirmation sert le mieux comme dernière ligne de défense. Il a atteint des hauteurs intangibles et intouchables sous le langage C, lorsque ce langage a régné sur le monde, comme un excellent moyen de mettre en œuvre la "nouvelle programmation défensive"; il reconnaît et piège les catastrophes catastrophiques au moment où ils sont au bord du gouffre. C'était avant que la valeur des tests ne soit largement reconnue et respectée et que les catastrophes ne deviennent beaucoup plus courantes.
Aujourd'hui, il est impensable qu'un logiciel commercial sérieux soit commercialisé sans aucune forme de test. Les tests sont pris au sérieux et ont évolué pour devenir un vaste domaine. Il existe des professionnels des tests et des départements d’assurance qualité dotés de listes de contrôle volumineuses et de signatures officielles. Dans ces conditions, les programmeurs ont tendance à ne pas s'embarrasser d'assertions, car ils ont la certitude que leur code sera soumis à des tests si fastidieux que les probabilités de conditions délirantes au bord de la catastrophe sont si minimes qu'elles sont négligeables. Cela ne veut pas dire qu'ils ont raison, mais si la responsabilité de la programmation paresseuse peut être transférée au service d'assurance qualité, pourquoi diable?
Je ne suis l'auteur d'aucun de ces projets, donc ce n'est qu'une supposition basée sur mes propres expériences. Sans demander directement aux personnes participant à ces projets, vous ne obtiendrez pas de réponse concrète.
Assert est génial lorsque vous essayez d'effectuer un débogage, etc. dans votre propre application. Comme indiqué dans le lien que vous avez fourni, l'utilisation d'un conditionnel est préférable lorsque l'application est capable de prédire et de récupérer à partir d'un état. Je n'ai pas utilisé zope, mais dans Twisted et Django, leurs applications sont capables de récupérer et de continuer à partir de nombreuses erreurs dans votre code. En un sens, ils ont déjà «compilé» les assertions puisqu'ils peuvent réellement les gérer.
Une autre raison, liée à cela, est que souvent les applications utilisant des bibliothèques externes telles que celles que vous avez énumérées peuvent vouloir gérer les erreurs. Si la bibliothèque utilise simplement des assertions, quelle que soit l'erreur, elle déclenchera une AssertionError. Avec une version conditionnelle, les bibliothèques peuvent en réalité générer des erreurs utiles qui peuvent être détectées et traitées par votre application.
Selon mon expérience, asserts sont principalement utilisés dans la phase de développement d'un programme pour vérifier les entrées définies par l'utilisateur. asserts ne sont pas vraiment nécessaires pour détecter les erreurs de programmation. Python lui-même est très bien capable de piéger de véritables erreurs de programmation telles que ZeroDivisionError, TypeError ou à peu près.