วีดีโอ

Oui, tu ne pourras pas les utiliser dans des versions antérieures, tu auras une erreur de syntaxe

@@codeavecdave est-il préférable de passer sur une version qui le support ou n'est-ce pas nécessaire ?

Je te conseille d'aller en 3.12 car c'est la dernière version stable

Ce sont des méthodes reservées aux fonctionnalités internes de Python, il ne faut donc pas essayer d'en créer soi-même. En soi c'est des méthodes classiques mais c'est simplement comment elles sont utilisées derrières par Python

elle n'est pas incontournable mais elle propose un panel très large de types, classes et décorateurs très utiles pour les annotations de types ou ici pour définir plus explicitement le type de comportement attendu sur les classes et méthodes. De manière générale les objets de typing ne sont pas considérés par l'interpréteur de python mais sont utilisés par le type checkeur statique (ex. mypy), et permettent un code bien plus lisible et explicite globalement

Le module typing reste de la documentation personnalisée. Par exemple pour Final tu documentes juste le fait que tu ne veux pas qu'on réécrive ta méthode. Mais au lieu de le mettre dans un commentaire ou dans la doc de ta fonction ça affiche des trucs dans ton éditeur (ici un beau soulignage rouge si tu réécris la méthode). Mais ça ne changera jamais rien à la logique de ton code

La programmation fonctionnelle est incroyable c'est vrai mais pourquoi selon toi la programmation orientée objets est "inutile" ?

A mes yeux les classes ça permet de faire facilement ce qui est souvent difficile avec des fonctions en terme d'orga et de lisibilité. Même si je préfère de très loin la POO (à mes yeux bien plus naturel sur des projets) je pense que le style le plus complet et facile à lire ça doit être celui où les 2 sont utilisés et se complètent.

Je suis 100% d'accord avec toi​@@flastar1295

ca depend mais c vrai que dans le web on utilise plus souvent de fonction ou des script coté server apres pour certaine features qui ont besoin de methode et d'effectué des operation différente sur un objet dans ce cas se sera mieux une class un bete exemple pour gerer les differente operation avec la data base on va préferer crée une class database avec dans le constructor la connexion a la database et ainsi une fois la class instancier tu peux appeler toute tes methode pour crée tes tables, les modifier editer des rangée,... par exemple dans le cas de l'interaction avec une database sql j ai jamais vue aucun dev faire autrement qu'avec une class c'est pourquoi ca depend des cas mais si tu fais des systeme avancé un moment ou un autre tu aura besoin de créer des class pour mieux strucuturé et mieux auto documenté ton code

Les classes ne sont pas inutile. C'est un outil tout comme la prog fonctionnelle.

pas de membres privés, neither. Still, on est pas en java

Pourquoi ?? Je suis curieux d'avoir ton avis. C'est des fonctionnalités de POO pas de java

On va nuancer un peu des 2 côtés : -> La POO fonctionne différemment dans tous les langages. Tant dans les concepts que dans la philosophie. Donc effectivement l'argument "c'est juste de la POO" n'est pas valable puisque ce n'est pas comparable -> Effectivement en Python on ne met pas systématiquement en "privé" (et on ne met pas en privé avec un double underscore pitié) -> Ça ne veut pas dire qu'on ne doit jamais utiliser l'encapsulation non plus. Les propriétés et descripteurs ne sont pas là pour faire joli. -> Donc on "met en privé" s'il y a information sensible et SURTOUT s'il y a vérifications des valeurs

​@@anyone3807 Merci beaucoup pour ton avis, mais j'avoue que je ne le partage pas du tout L'encapsulation est un concept fondamental de la POO, ça n'a pas vraiment de sens de penser que c'est individuel à chaque langage. Mettre un attribut en privé n'est pas non plus réservé à un langage de programmation, ça arrive lorsque comme tu l'as dis on a des vérifications de valeur à faire ou pour n'importe quelle autre raison où l'accès à cette donnée pourrait être mauvais. Quand tu commences à développer des projets assez gros, tu comprends que l'encapsulation peut vraiment aider à baisser le couplage et augmenter la cohésion de ton composant. Les propriétés sont une fonctionnalité exceptionnelle qui permettent de mettre en place de l'encapsulation sans avoir à utiliser une syntaxe de fonction. Comme tu l'as dis, elles ne sont pas là pour faire joli. Tu peux les utiliser pour créer des attributs dynamiques ou plus souvent pour encapsuler des données puisque ce sont des descripteurs avant tout J'ai regardé le lien que tu as envoyé par rapport aux simple et et doubles underscores pour les variables privées et à vrai dire ça ne change pas grand chose. On mets uniquement un underscore lorsque l'attribut est protégé et donc accessible uniquement dans la classe où se trouve l'attribut et dans ses filles. On en mets deux lorsqu'elle est vraiment privée c'est-à-dire accessible que dans la classe où se trouve l'attribut. C'est pour ça qu'on a du name mangling, pour qu'il n'y ait pas de problème si on veut définir un attribut avec le même nom dans la classe fille. J'aime beaucoup ce genre de commentaires parce que je pense que ça peut aider d'autres développeurs qui ont encore du mal avec la POO. Si tu souhaites un peu mieux comprendre l'orienté objets et surtout l'encapsulation du coup, je te conseille d'aller lire Object Thinking de David West et Elegant Objects de Yegor Bugayenko. Ce sont deux pépites qui permettent de comprendre beaucoup mieux la philosophie orientée objets et comment l'appliquer dans nos projets. Merci encore pour ton message ;) !

Je n'ai pas dit que l'encapsulation était indivuduel à chaque langage mais que la POO fonctionnait différemment. Les concepts et les bonnes pratiques ne sont pas du tout les mêmes. - Dans certains langages on a les interfaces, en Python y a pas - Dans certains langages on a l'héritage multiple et pas dans d'autres - Dans certains langages on a les attributs protégé et pas dans d'autres et quand il y est, leur fonctionnement n'est pas le même - Dans certains langages on a les traits et pas dans d'autres - Dans certains langages on utilise des design pattern qui sont contre-productifs dans d'autres... Après oui, il y a des concepts qu'on retrouve un peu partout mais selon les langages, la POO s'éloigne plus ou moins de UML. Il y a même certains langages ou la POO ne fonctionne pas avec des classes mais avec des prototypes. Un argument que je vois beaucoup trop souvent de la plupart des devs source de mauvaises pratiques "La POO (dans le sens traditionnel UML) prime sur les bonnes pratiques du langage". sauf que non, dans le cas où c'est faisable, c'est à cause de ça qu'on se retrouve par exemple avec des devs java qui font des getter et des setter partout qui ne font que renvoyer/modifier un attribut (en gros qui ne sert à rien) sans même utiliser les propriétés. Les propriétés sont un mécanisme mis en place par Python pour permettre de faire de l'encapsulation selon la philosophie du langage. Je ne comprends absolument pas quand tu dis "encapsulation sans fonction". Tu as une syntaxe alternative qui te permet de faire justement ceci sans decorateurs avec la fonction property. Non ce que tu dis est absolument faux, la notion d'attribut protégé n'existe pas en Python. Tu peux retourner la doc officielle et la PEP 8 dans tous les sens, absolument personne n'en parle. Ça c'est juste une idée reçue venue de développeurs d'un autre langage qui ont voulu recalquer leurs concepts en Python. Au contraire Python a toujours été contre les attributs protégés. Comme quoi même les "experts Python" n'ont même pas toutes les informations. Je t'ai mis la PEP 8 des conventions officielles de Python qui explique noir sur blanc que les attributs privés sont précédés d'un seul underscore et tu arrives encore à me contredire sur ce sujet en me disant que ca se fait avec un double, c'est une preuve que soit tu n'as pas lu ce que je t'ai envoyé, soit tu fais preuve de mauvaise foi puisque c'est un classique chez les développeurs de ne pas se remettre publiquement en question. Et non, la surcharge d'attribut n'a absolument aucun rapport avec les attributs privés. Je ne vais pas être hypocrite. Je déteste prendre de mon temps pour faire un gros pavé pour expliquer quelque chose à quelqu'un, donner des ressources dont certaines officielles pour appuyer mon argument et me faire contredire sur des points qui sont objectivement faux et recevoir des conseils derrière basé sur un sentiment de superiorité "eh tu t'es trompé mais c'est pas grave, lis ça et tu comprendras tout autant que moi". Vraiment désolé cependant pour mon ton virulent. Et je te remercie également pour le temps que tu as pris ainsi que pour les livres. Moi je vais m'arrêter là. Peut être que tu m'en voudras pas trop. Que tu sois d'accord avec moi ou non, j'ai dit tout ce que j'avais à dire et continuer ne serait qu'une perte de temps pour nous. Bonne continuation

C'est pour l'exemple

Complètement d'accord et pourtant je connais des développeurs professionnels qui font ça

C'est un moyen simple et super efficace de résoudre ce problème oui

Un dictionnaire en python est un mapping donc simplement une représentation des données sous forme clé-valeur, c'est simplement une structure de données. Ce n'est pas comme en TS où les dictionnaires peuvent être utilisés comme des objets

@@codeavecdave et donc ?

​@@ilian572 ce n'est pas une faute en soit de représenter une ville via une structure. Mais disons que c'est généralement plus adapté d'avoir une class, dans la mesure où un système complexe comme une ville peut nécessiter l'ajout de fonctionnalités supplémentaires, ou devoir hériter de système parents (comme un système plus général qui s'appelle : ville) De même, l'allocation mémoire entre une struct et une class n'est pas la même, en tout cas en c++, je ne sais pas pour python. Représenter des floats, int, str : struct Représenter des objets complexes (voiture, avion, ville, personne...) : class

@@emelineclank9448 parfois un dictionnaire suffit

@@ilian572 absolument. Généralement, c'est lorsqu'il n'y a aucune méthode associée au code. Je pense que l'objectif de sa vidéo, est de pointer du doigt ceux qui oublie l'existence des class. Comme certains débutant qui utilisent des dict, et font du traitement de la donnée sur le dict. --> les classes sont faites pour ça. Mais tu as raison. De toute manière, une classe est un dictionnaire quand on creuse alors bon ...

Merci beaucoup ! Tu as complètement raison, j'aurais du renvoyer une erreur

Les classes en python sont plus lourdes que des dict, donc si tu veux simplement représenter des valeurs, sans avoir besoin d'ajouter des méthodes spécifique pour cette classe, ou avoir besoin des méthodes type __add__, __sub__ etc.. Tu préfères utiliser des typedDict. Aussi, comme c'est des dictionnaire ca peut etre plus facile à intégrer avec du code existant qui utilise déjà des dictionnaires, plutot que de tout changer pour ca fonctionne avec des classes

C'est exactement ça, ici le gros avantage des TypedDict est de pouvoir créer des structures de données simples qui sont basées sur les dictionnaires un peu comme les objets en TypeScript

Oui c'est ça, je ne vois pas pourquoi je n'y avait pas pensé

J'y avais pas du tout pensé mais c'est évident quand tu le dis, merci beaucoup !

Merci beaucoup !!

Parfait ça, merci beaucoup ! Bon courage !

Merci beaucoup !

3.8 pour la base, certaines des features ne sont arrivées que plus tard par contre (Required et NotRequired en 3.11 par exemple).

D'ici quelques semaines, je vais commencer à sortir des vidéos sur tous les design patterns les plus importants :)

Franchement ça fait super plaisir de lire ce genre de commentaires ! C'est avec plaisir ! J'ai vraiment envie de créer un maximum de contenus pour expliquer les concepts les plus avancés de Python et de l'informatique en général donc j'espère que les prochaines vidéos pourront aussi t'aider ;)

Ce ne sont pas des dictionnaires mais des classes, donc tu peux leur rajouter des méthodes, elles ont un __repr__ spécifique, ...

@@thuiop1 Je me demande donc quel est l'avantage des TypeDicts vs les dataclasses... Personnellement j'utilises des dataclasses et je ne vois pas d'inconvénient pour l'exemple montré.

Tu peux utiliser Mypy

Normalement c'est de base dans ton IDE, mais sinon c'est soit la librairie mypy ou pyright qui permet cela

En fait reduce est fondamentalement différent, mais c'est peut-être un peu moins apparent en python parce que map ne retourne pas une liste quand tu lui donnes une liste, alors qu'il "devrait" (en tout cas s'il veut s'appeler "map"). Reduce est un catamorphisme, c'est à dire qu'il détruit la structure de départ pour te permettre d'en extraire les valeurs, alors que map te retourne la même structure avec les valeurs modifiées. Le hic quand on implémente reduce sur une collection (parce que c'est pas obligé) c'est qu'une collection a plusieurs valeurs, or tu ne peux pas retourner plusieurs valeurs à moins de les mettre dans une nouvelle structure ou de les résumer à une seule valeur. C'est donc ce qu'on fait quand on utilise reduce : Soit on définit un accumulateur initial qui va être la nouvelle structure que l'on remplit incrémentalement ; Soit on réduit les valeurs à une seule valeur. Raisonner de façon abstraite lorsqu'on utilise reduce est la seule façon de bien l'utiliser. C'est une abstraction très puissante quand tu la couples aux monoïdes et semi-groupes. Si tu l'interprètes comme une façon bizarre d'itérer, il vaut mieux simplement boucler

C'est une très bonne idée et c'était prévu de développer une vidéo pour regrouper les deux. Merci beaucoup !

Merci beaucoup ! J'ai commencé l'informatique il y a 4-5 au lycée puis j'ai continué en fac d'informatique. La réalité est que je n'ai pas appris grand chose dans dans ces formations, la majorité de mon apprentissage a été dans les livres pour les concepts de développement de logiciels de haute qualité et les documentations officielles pour les langages de programmation et les librairies

@@codeavecdave J’imagine que vous avez donc développé des librairies en python ?

Merci beaucoup !

Oui c'est pas facile au début. Merci beaucoup !

Ouais j'avoue c'était horrible

Oui du coup

Il n'y a pas de fallthrough quand il y a pattern matching.

Merci beaucoup ! On peut parfois se dire que c'est inutile de créer trop de petites pièces mais le plus souvent ça crée un code plus simple à comprendre et qui est surtout bien plus maintenable