Je me trouve essayer de convertir des paramètres de constructeur vers leurs types de droite très souvent dans mes programmes Python. Jusqu'à présent, j'utilise du code similaire à cela, donc je n'ai pas à répéter les arguments d'exception: est-ce une bonne pratique? Devrais-je simplement ne pas prendre la peine d'attraper des exceptions sur la conversion et de les laisser se propager à l'appelant, avec l'inconvénient possible d'avoir des messages d'erreur moins significatifs et cohérents?
3 Réponses :
Vous pouvez utiliser un type de décorateur de vérification comme Cette recette ActiveState ou Cet autre pour Python 3 . Ils vous permettent d'écrire un code quelque chose comme ceci: qui soumettra une exception si les arguments ne sont pas du type requis. Vous pouvez facilement étendre les décorateurs pour vérifier que les arguments ont des valeurs valides ASWELL.
Ces recettes de décorateur sont agréables (et elles sont facilement désactivées si vous n'en avez plus besoin).
Cela semble être la solution la plus élégante jusqu'à présent, je vais certainement le vérifier. Sur une note non liée, Activeestate.com Hang Firefox (10.0) pour quelqu'un d'autre?
Ceci est subjectif, mais voici un contre-argument: attendre, quoi? Cela devrait être un ok, donc cela viole les principes "dactylographie du canard". Mais je n'utiliserais pas de dactylographie de canard pour des objets primitifs tels que typeError . Je ferais ceci: int .
Quand j'ai une question comme celle-ci, je vais chasser dans la bibliothèque standard pour le code que je peux modéliser mon code après. multiprocessing / piscine.py a une classe quelque peu proche de la vôtre: xxx pré>
Notez que cela ne dit pas p>
class ClassWithThreads(object):
def __init__(self, num_threads):
self.num_threads = num_threads
if self.num_threads < 1:
raise ValueError('Number of threads must be at least 1')
Cette approche ne serait-elle certainement pas échouer très imprévisible pour certaines conditions? Par exemple, le passage d'une chaîne ne serait pas attrapé comme une erreur du tout (car ils ne compareront jamais comme <1 ). Mon intention des contrôles préventifs tente de garantir une certaine cohérence dans l'état de l'objet, détecter les erreurs le plus tôt possible au lieu d'avoir une exception associée au hasard être lancée plus tard. Est-ce que c'est «plus pythonique» de simplement laisser les choses être et échouer à une fois plus tard?
Si ce n'est pas une interface de l'utilisateur, laissez-la intacte et laissez l'exception se propager naturellement. Vous faites plus de travail pour vous-même et enveloppez l'exception n'ajoute pas beaucoup de valeur.