Python conventions de nom de package
Existe-t-il une convention de dénomination des packages pour Python comme Java com.company.actualpackage? La plupart du temps, je vois des noms de packages simples et potentiellement en collision comme " web ".
S'il n'y a pas une telle convention, y a-t-il une raison à cela? Que pensez-vous de l'utilisation de la convention de dénomination Java dans le monde Python?
Python a deux "mantras" qui couvrent ce sujet:
Explicite vaut mieux qu'implicite.
et
Les espaces de noms sont une excellente idée de klaxon - faisons-en plus!
Il existe une convention pour nommer et importer des modules qui peut être trouvée dans The Python Style Guide (PEP 8).
La principale raison pour laquelle il n'existe pas de convention de ce type pour préfixer systématiquement les noms de vos modules dans un style Java, c'est parce qu'au fil du temps, vous vous retrouvez avec beaucoup de répétitions dans votre code qui n'ont pas vraiment besoin être là.
L'un des problèmes avec Java est qu'il vous oblige à vous répéter constamment. Il y a beaucoup de passe-partout qui va dans Java code qui n'est tout simplement pas nécessaire) en Python (les Getters/setters en sont un excellent exemple.)
Les espaces de noms ne sont pas vraiment un problème dans Python parce que vous pouvez donner un alias aux modules lors de l'importation. Tels que:
import com.company.actualpackage as shortername
Ainsi, vous êtes non seulement capable de créer ou de manipuler l'espace de noms au sein de vos programmes, mais vous pouvez également créer vos propres alias d'économie de frappe.
Les conventions Java ont également leurs propres inconvénients. Tous les packages opensource n'ont pas de site Web stable derrière. Que doit faire un mainteneur si son site Web change? En outre, l'utilisation de ce nom de package devient longue et difficile à retenir. Enfin, le nom du package doit représenter le but du package, pas son propriétaire
Il n'y a pas de convention de dénomination de type Java pour les packages Python. Vous pouvez bien sûr en adopter un pour tout package que vous développez vous-même, mais vous devrez peut-être modifier de manière invasive tout package que vous pourriez adopter de tiers, et la convention de dénomination "culturellement étrangère" sapera probablement les changements de vos propres packages pour qu'ils soient largement adoptés en dehors de votre organisation.
Techniquement, il n'y aurait rien de mal à la convention de Java dans Python (cela ferait juste quelques from instructions un peu plus longtemps, pas grand-chose), mais en pratique les aspects culturels font c'est à peu près impossible.
La raison pour laquelle il n'y a normalement pas de hiérarchie de packages est que Python ne sont pas facilement étendus de cette façon. Les packages sont de véritables répertoires, et bien que vous puissiez faire en sorte que les packages apparaissent dans plusieurs répertoires pour les sous-modules (en ajoutant dans les répertoires __path__ liste du paquet) ce n'est pas pratique, et cela se fait facilement mal. Quant à pourquoi Python ne sont pas facilement étendus de cette façon, eh bien, c'est un choix de conception. Guido n'aimait pas les hiérarchies profondes (et toujours pas) et ne pense pas qu'ils sont nécessaires.
La convention consiste à choisir un nom de package de niveau supérieur évident mais unique pour votre projet - par exemple, le nom du projet lui-même. Vous pouvez tout structurer à l'intérieur comme vous le souhaitez (parce que vous en avez le contrôle.) Le fractionnement du package en bits séparés avec des propriétaires distincts est un peu plus de travail, mais avec quelques directives, c'est possible. C'est rarement nécessaire.
Il n'y a rien qui vous empêche d'utiliser cette convention si vous le souhaitez, mais ce n'est pas du tout standard dans le monde Python et vous obtiendrez probablement des regards drôles. Ce n'est pas très amusant de prendre soin de l'administrateur sur packages lorsqu'ils sont profondément imbriqués dans com.
Cela peut sembler bâclé à quelqu'un qui vient de Java, mais en réalité, cela ne semble pas vraiment avoir causé de grandes difficultés, même avec des packages aussi mal nommés que web.py.
L'endroit où vous obtenez souvent les conflits d'espace de noms dans la pratique est les importations relatives: où le code dans package.module1 essaie de import module2 et il y a à la fois un package.module2 et un module2 dans la bibliothèque standard (qui existe généralement car le stdlib est grand et en croissance). Heureusement, les importations relatives ambiguës disparaissent .
J'utilise python depuis des années et 99,9% des collisions que j'ai vu venir de nouveaux développeurs essayant de nommer un fichier "xml.py". Je peux voir certains avantages du schéma Java, mais la plupart des développeurs sont assez intelligents pour choisir des noms de packages raisonnables, donc ce n'est vraiment pas un gros problème.