Si tu souhaites devenir un expert de Python et apprendre à créer un code exceptionnel : developerssecrets.com Si tu veux rejoindre une communauté de développeurs actifs et motivés : / discord
Je pense que c'est plus pratique et safe de faire ça au niveau du système de type: `Priority = Literal['low'] | Literal['medium'] | Literal['high']` - Une union te donne plus de confort au niveau de l'auto-complétion parce que tu n'as que 3 suggestions (et pas tous les attributs et méthodes de ta class Priority). - Elle te donne aussi plus de confort et de sécurité si tu utilises match/case, parce qu'à chaque `case` que tu ajoutes, la liste des suggestions va se réduire (même si mypy ne check absolument pas l'exhaustivité ou la répétition des cases) - Utiliser des valeurs numériques automatiques est embarrassant quand tu dois ajouter une valeur intermédiaire, du genre 'medium-high': avec une énumération ça va incrémenter 'high', ce qui veut dire que tu ne dois jamais faire persister un enum en utilisant sa valeur numérique, il faut donc prévoir une étape de conversion en string supplémentaire quelque part. Pour aller plus loin, une union de types (ou type somme) permet d'avoir une approche fonctionnelle qui bénéficie du fait que l'état de ton Ticket peut être représenté au niveau des types pour rendre les états illégaux impossibles à représenter sans te faire engueuler par ton IDE (à condition de créer des Tickets immutables, donc des "value objects") Par exemple tu pourrais, au niveau du système de type, rendre impossible de fermer un ticket qui n'est pas dans l'état 'in progress' ; tu pourrais rendre impossible la création d'un ticket qui soit à la fois 'low' et 'closed' (Ça n'a pas de sens ici mais quand tu as deux états orthogonaux il arrive souvent que certaines combinaisons soient illégales) ; ou plus simplement tu peux rendre illégal le fait d'appeler une fonction `next()` sur un Status 'closed' parce que 'open' n'est pas la suite logique de 'closed'. Au contraire, gérer un overflow sur un enum avec un modulo, ça peut être traitre. Pour faire ça en Python, j'ai l'impression que le plus propre c'est de refactor ton union comme ceci: `Priority = Low | Medium | High` avec des alias pour chaque valeur (`Low = Literal['low']`, etc.) que tu peux utiliser comme type hint dans des fonctions. Le système de type de Python a beau être immature, il a déjà mieux à proposer que l'approche OOP classique.
C'est un raisonnement que j'essaye d'utiliser de plus en plus dans mon code parce que c'est une solution simple mais beaucoup plus puissante. En soi, même si le but de la vidéo était de présenter les énumérations, en production je pense que ta solution serait meilleure et plus maintenable
Petit addendum, j'ai remarqué que en tout cas sur VS Code avec Pylance et typing.TypeVar + typing.Generic, tu ne peux pas avoir d'auto-completion sur une contrainte de type quand tu instancie une class. Tu as bien des erreurs quand tu mets la mauvaise valeur, mais c'est pas méga pratique. J'espère que ce sera réglé avec l'implémentation de PEP 695. parce que si tu veux définir une méthode ou une fonction `close(self: 'Ticket[Priority, InProgress]')` il te faut absolument des génériques
Merci, c'est super instructif. Si tu as le temps un de ces quatre, pourrais tu faire une video explicative sur l'asynchrone/synchrone ? c'est un peu Cho comme concept pour moi mais comme tu explique vraiment bien
Merci beaucoup ! Je pense que je ferais une grosse vidéo sur ce concept parce que c'est super important à comprendre mais c'est sûr que je vais faire des vidéos dessus
mais c'est tellement pratique comme feature ! j'ai actuellement un projet qui serait pas mal simplifié en introduisant ces énumérations aux bons endroits, merci beaucoup pour le tips !
Par contre il faut noter quand même que les enums ne t’empêchent pas de faire ticket.status = "abc". Techniquement, c’est toujours faisable, les joies de python 🙃
Oui ça reste possible de faire encore n'importe quoi sans erreur de compilation. Malgré tout, on aura quand même des erreurs dans l'IDE ce qui est le plus souvent suffisant
Les enums avec des valeurs en int, je trouve ça très peu pratique. Heureusement, Python supporte ça: class Status(Enum): OPEN = "open" CLOSED = "closed" Quand on veut passer d'une str à l'enum, il suffit de faire Status(api.new_status) et c'est très bien. Django fonctionnait historiquement avec des choices: OPEN = "open" CLOSED = "closed" STATUS_CHOICES = ( (OPEN, "Open"), (CLOSED, "Closed"), ) Maintenant, on peut utiliser des enums aussi mais je trouve que ça reste assez clunky comme intégration. Par contre, Graphene ne m'a apporté que des problèmes avec les enums.
