D’abord on crée un enum avec les valeurs possibles en entrée :

class Gender(enum.Enum):

female = 0

male = 1

other = 2

Puis on l’appelle dans la classe modèle

class Content(db.Model):

…

gender = db.Column(db.Enum(Gender), nullable=False)

…

Ça permet de faire ensuite le mapping en écriture et en lecture sur ses requêtes. Est-ce que ça aurait marché pareil avec un dico? I don’t know :]

parser.add_argument("--set", choices=[monenum.value for monenum in MonEnum])

Comme ça, je peux facilement lier un affichage avec un identifieur qui ne sera pas forcément le même.

Je sais que la valeur est correcte et validée par argparse. Je peux alors facilement utiliser MonEnum(args.set) dans le reste du code.

Je trouve ça sympa de ne pas avoir à risquer de me tromper quand la valeur de l’enum n’est pas la même que le nom.

Stuff = namedtuple(‘Stuff’, ‘FOO BAR DOH OYO’)(*range(1, 5))

Le 1er “Stuff” est un objet, pas une classe, le nom devrait commencer par une minuscule, stuff.

C’est namedtuple(‘Stuff’, ‘FOO BAR DOH OYO’) qui est une classe de nom Stuff

ça m’a perturbé un moment

Par exemple, tu parles de refactoring. Mais en en Python le refactoring est rarement un gros problème comme dans d’autres langage. Le duck typing, le typage dynamique et les outils mis à disposition font que c’est presque toujours beaucoup plus facile et rapide en Python.

Il faut utiliser les outils dans un contexte où leurs bénéfices sont supérieurs à leur coût. En Python, de nombreux outils d’autres langages sont inutilement lourds ou compliqués. Chaque usage d’un outil de plus demande à connaitre une chose de plus pour comprendre et utiliser le code.

l’exemple que tu prends se base sur les verbes HTTP qui sont d’une part peu nombreux, et d’autre part normalisés. C’est rarement le cas du code qu’on écrit. Par exemple si tu veux gérer le statut d’un type d’objets, le fait d’utiliser un enum’ permet de normaliser la liste des valeurs possibles, donc il est plus rapide de monter en compétence sur le code
l’utilisation de “string” est un anti-pattern, et pose de gros problèmes en terme de refactoring, mais également d’efficacité : le mec qui tape ‘GEt’ va perdre du temps à détecter qu’il a fait une faute de frappe là où l’utilisation d’une constante permettra de visualiser l’erreur immédiatement (par exemple avec PyCharm, c’est le cas)

Vouloir utiliser des string “parce que c’est plus simple/souple” c’est comme de dire “on va utiliser des dictionnaires au lieu de classes”. Tant que tu travailles tout seul, c’est pas un problème, par contre quand tu travailles en équipe, c’est bien de savoir ce que le code de ton collègue attend comme structure, c’est de l’auto-documentation.