Propre, un format magnifique j’adore. J’étais justement en train de chercher comment fonctionne le mot « CONTINUE ». Vous venez de me l’apprendre, comme d’habitude on apprend toujours des nouvelles choses à chaque vidéo. Continue comme ça. continue 😅
L'extension "Sourcery" pour VS Code est ultra pratique pour ce genre d'inattentions, je l'avais découverte dans ta vidéo sur les 5 extensions indispensables 😁
Par rapport à la correction sur le check d'intervalle (autour des 6 minutes) je pense qu'il aurait été de bon goût de dire que c'est une construction python qui ne se retrouve pas dans tous les langages, et qui est une GROSSE source d'erreur pour les débutant-e-s quand iels apprennent le C/C++ par exemple Si on écrit la même chose en C on aurait `1
Hello, jamais fait de Python = assez perturbé par les semi-columns 404. Je bosse depuis 2 ans dans le milieu et franchement, sympa comme vidéo à avoir en fond :). Je vais de ce pas aller voir ce que tu as dans le même genre d'accessible for All. Je cherche des thèmes genre : Quand passer par un Design Pattern, Objets ou Variables ? Classes ou pas besoin ? etc.
Vraiment intéressant de voir ta façon de raisonner ! Quelque question : 1 - Quand on veut vider une liste, vaut t'il mieux faire ma_list.clear() ou ma_list = [] ? Ou c'est la même chose fonctionnellement ? 2 - Qu'en penses tu de passer par un dictionnaire pour remplacer toute les strings qui sont dans dans print ? Par exemple : statut_dict = { "choice_menu": "faite votre choix", "add_product": "produit a ajouter", "quit": "vous avez quitter le programme", } Alors oui dans ce genre de cas, avec tout les condition, ça fait un gros pathé et ça serait mieux qu'il y ai un fichier juste pour le dictionnaire complet ^^ Mais ça rajouterai de la visibilité dans le code je trouve
[] assigne une nouvelle liste vide à la variable, tandis que clear() supprime réellement tous les éléments de la liste. Cela peut causer des problèmes lorsque 2 variables pointent sur la même liste. Si tu fais clear() sur l'une, l'autre sera aussi vide, si tu assignes [], l'une sera vide, l'autre non (car l'autre existe toujours, c'est juste qu'elle n'est plus pointée). Si on devait optimiser la mémoire, clear() est mieux car on ne recrée pas de liste à chaque fois, laissant des listes non pointées derrière (même si elles finiraient par se faire virer de la mémoire)
2 года назад
@@RisingSunLightRSL Par ailleurs, à mon sens, l'autre avantage d'utiliser "clear" est tout simplement d'être explicite sur l'intention (indiquant clairement que a) on s'attend à agir sur une liste non vide b) on veut bel et bien la vider entièrement). C'est un détail sur des codes simples comme ça, mais quand les scripts se complexifient en centaines de lignes sans pour autant être réécrits en forme fonctionnelle, il devient plus difficile de mémoriser les "points d'affectation et d'usage" de chaque variable. D'où l'intérêt de distinguer immédiatement "affectation d'une liste vide" (qui pourrait être une initialisation de variable) de "vidange d'une liste par clear". AMHA.
La vidéo est très bien, et l'idée est très bonne, la plupart des conseils sont excellents et, je pense, peuvent aider les débutants. Cependant, j'ai remarqué plusieurs choses qui n'allaient pas dans les conseils données. 1er code : - Il ne faut jamais écrire "1
Salut, merci pour ton commentaire ! Je vais cependant m'inscrire en faux sur plusieurs points. Pour le premier point je peux comprendre effectivement qu'on souhaite faire comme dans d'autres langages. Mais c'est une possibilité offerte par Python, je trouverais dommage d'essayer de se calquer complètement sur d'autres façons de faire. Dans ce cas, il y beaucoup de choses qu'on devrait laisser tomber en Python car le langage n'est pas construit de la même façon que d'autres langages. Sur ce point, c'est donc plus une question de préférence je trouve mais je peux comprendre qu'on préfère être plus explicite. Pour l'espace après les 2 points par contre je ne suis pas d'accord. Déjà je ne suis pas d'accord sur le fait que plus il y a d'espaces plus ça respire. Dans ce cas-ci je trouve ces espaces vraiment superflus et je trouve que ça complexifie la lisibilité. Dans ce cas on peut mettre des espaces et sauter des lignes partout et ça sera vraiment espacé. Mais plus d'espace n'est pas toujours égal à une meilleure lisibilité selon-moi. Et surtout, au delà du subjectif, c'est la PEP-8 qui recommande de ne pas mettre d'espace avant les 2 points : peps.python.org/pep-0008/#whitespace-in-expressions-and-statements Je conseille toujours de suivre les recommandations de la pep-8. Tous les scripts Python que je vois passer n'ont pas d'espaces avant les 2 points, donc ce serait aller à contre courant de tout le monde que d'en rajouter un. Pour le 2e code je suis d'accord avec toi mais j'ai oublié de préciser au début de la vidéo le contexte de l'exercice. À ce stade de la formation les fonctions n'ont pas encore été vues. Il y a beaucoup de choses donc qui pourraient être améliorées et séparées avec des fonctions mais là l'idée était surtout de montrer la boucle while et les différentes options de contrôle comme continue ou break ainsi que les structures conditionnelles. Pour le 4e code, là encore pour les séparateurs c'est assez subjectif. Je trouve qu'une ligne "print(separator)" est tout aussi efficace et facile à comprendre que de devoir copier coller et répéter à chaque fois une longue ligne de caractères. Quant au fait de les laisser, si on veut vraiment laisser du debug je passerais plutôt par le logging que par un if debug, mais là encore ce n'est pas quelque chose qui est vu à ce stade de la formation. Dernier point concernant les noms de variables, je ne suis pas d'accord là encore 😅 Je trouve que jamais des noms de variables ne devraient être aussi peu explicite. Il faut s'habituer à écrire un code clair, et des noms de variables comme msg ou elt ne parlent pas à tout le monde. On n'est plus dans les années 80 avec des écrans minuscules, on peut avoir le luxe de créer des noms de variables plus explicites, et si une ligne devient trop longue, c'est généralement qu'il y a trop de choses en même temps sur la ligne et qu'elle peut être séparée en plusieurs lignes. Mais réduire la surcharge du code et vouloir améliorer la lisibilité en utilisant des noms de variables peu explicites n'est selon moi pas la bonne façon de faire. Une part de subjectif du coup dans le code de chacun bien sûr, mais sur les points spécifiques à la pep-8 je serai plus catégorique ^^ Merci en tout cas pour ton retour d'expérience et ton commentaire qui permettent de confronter les points de vue :) Bonne continuation de même !
@@Docstring J'ajouterais même que l'idéal serait d'utiliser les breakpoints, c'est une fonctionnalité qu'on retrouve dans la plupart des IDE, qui est assez simple à comprendre et qui évite les print() superflus.
@@qexat Effectivement, après je pense que dans certains cas un print peut encore être intéressant, j'en parlais dans cette vidéo : ru-vid.com/video/%D0%B2%D0%B8%D0%B4%D0%B5%D0%BE-Ss73b4G5uaA.html Le problème du debug c'est que ça peut quand même varier d'un éditeur à un autre, même si les concepts restent les mêmes. Un print pour des scripts très simple de ce genre, perso ça ne me dérange pas et ça évite de perdre pas mal de gens qui ne sont pas à l'aise avec un débugueur. Mais dans une formation complète effectivement c'est un outil indispensable.
Tu peux même aller encore plus loin, une liste de fonctions, dans chacune d'elle un docstring qui te sert de texte pour remplir ton menu. J'ai eu même poussé le vis plus loin à une époque, en utilisant l'introspection, quand tu rajoutais une méthode à une classe, cela t'ajoutais automatiquement un élément dans un menu tkinter, et les paramètres de chaque méthode, permettait d'ouvrir une boite de dialogue contenant la liste des params de la méthode avec deux boutons ok cancel. Sinon très bon tuto pour débutant.
Pour la plupart des corrections (j'ai survoler les dernieres), la condition du choix invalide peut se mettre à la fin des autres conditions avec simplement un else.
Effectivement! Parfait exemple dans lequel le match case serait une bonne alternative! Ce n'est encore pas un réflexe pour beaucoup de développeurs je pense. Mais je commence à utiliser l'opérateur walrus assez souvent et j'ai failli en parler ici d'ailleurs. On va s'y faire petit à petit à toutes ces nouveautés 😄
@@Docstring L'opérateur walrus est en effet un bon moyen d'améliorer la lisibilité du code tout en réduisant sa complexité ! C'est clair qu'en programmation, il faut toujours être à l'affût de chaque nouveauté 😁
@@hunzi4436 Effectivement après là ils nous en ont sorti tellement en 2-3 versions, on était pas habitué les pythoneux 😂C'est pas JavaScript et npm ici 😅
En tant que developpeur confirmé, je ne suis pas très fan des imbrications de else if, on aurait pu utiliser les hmap et faire un try catch pour verifier si l'entré est bien un int etc...
Effectivement, il y a plein de façons de rendre ce script plus pro, j'ai oublié de présenter plus en détail l'exercice et le moment à partir duquel il apparaît dans la formation (tout au début, après l'introduction des structures conditionnelles). L'objectif ici n'est donc pas de changer le code du tout au tout en faisant quelque chose de beaucoup plus optimisé mais qu'un débutant ne comprendrait plus, mais juste de prendre le code existant et de l'améliorer le plus possible en gardant l'idée de base du code :)
Effectivement mais il n'y en avait pas vraiment de bien plus originaux que ça. Le script 3 par exemple était assez original avec ses différentes structures. Mais je garde ça en tête oui pour les prochains, j'essaie toujours de trouver des cas de figure intéressants à corriger :)
Moi j'ai une question : faut-il faire du pseudo code avant de commencer à programmer car je suis étudiant et le professeur dis que c'est la clé pour pouvoir après le retranscrire dans n'importe quel langage. Je sais pas si tu as déjà abordé ce sujet dans une vidéo. J'aimerais avoir des conseils pour comment avoir le déclic en logique et programmation afin de créé du pseudo code sur feuille puis le taper sur la machine
Salut ! C’est une bonne étape à réaliser après ça dépend le programme et ton niveau, ce n’est pas non plus une nécessité absolue. Poser par écrit les bases de ce que tu veux faire c’est important après pas besoin non plus de faire l’intégralité de ton script en pseudo code avant de te lancer.
Je ne savais pas que tu faisais des corrections pour ce script. J'avais le même aussi, et j'ai fait plus ou moins la troisième version. Mais j'aurais aimé participer. Perso j'ai surtout appris sur les conventions (les espaces). Pour le reste je trouve que je suis un bon élève. La logique y est on va dire à 75% 80%. Je suppose que la partie fonction n'entre pas encore en compte... Pck dans mon script j'ai utilisé des fonctions (peut-être un peu de triche😋)
Salut Étienne! J'ai choisi de faire des corrections générales sur les différents exercices des formations. Sur Udemy il y a plus de 50,000 scripts qui ont été soumis au total sur les différents projets donc je ne peux pas faire de correction individuelle mais de toute façon ce sont souvent les mêmes erreurs qui reviennent. Et oui effectivement pas encore de fonctions à ce stade ci de la formation, je préciserai les notions vues pour les prochaines vidéos :)
@@Docstring merci bien. J'apprécie beaucoup la chaîne et le contenu me convient parfaitement. J'ai juste trouvé que ça allait un peu vite vers la fin, je ne voyais pas toutes les manipulations. Mais je comprenqis quand même. Ta pédagogie est au point. Merci encore
Effectivement, mais il me semble normal d'utiliser les possibilités du langage. Sinon on calque des façons de faire d'un langage sur un autre et on se retrouve à tous coder comme si on faisait du C, non ? Je n'ai jamais vu un script Python professionnel utiliser la syntaxe if len(liste) == 0, c'est pour moi redondant et je sais que Python est capable de comprendre la syntaxe simplifiée de if liste et je pense que dans ce contexte c'est donc préférable.
Hello docstring ! Alors je suis un peu d’accord avec le fait que len(liste) == 0 est mieux que not list car l’explicite est souvent mieux que l’implicite. Vu que python est un langage non typé, “liste” pourrait être une chaîne de caractères, un None, ou tout autre objet, qui s’évaluerait a “False” avec “If liste”. Écrire “len(liste) == 0” signifie au lecteur du code que l’on sait que cet objet est une liste. J’avais le même avis que toi il y a quelques temps mais j’ai changé d’avis après avoir review et vu pas mal d’erreurs sur cette question :) En tout cas super vidéo pour les débutants, bravo !
@@henrichabert6916 Salut Henri et merci pour ton retour ! Je comprends ton point de vue mais je reste convaincu qu'il est préférable de ne pas utiliser len (et je vais rajouter quelques arguments 😄). Tout d'abord, sur le fait que l'explicite est mieux que l'implicite, je suis tout à fait d'accord, mais la phrase qui suit celle-ci dans le PEP-20 / zen of python est "Simple is better than complex". Dans un cas comme celui-ci les deux principes peuvent se confronter l'un à l'autre, mais j'ai de mon côté bien plus souvent vu du code pro utiliser directement le concept de "truth value testing" que l'utilisation de len. C'est d'ailleurs une recommandation de la PEP-8 (peps.python.org/pep-0008/#programming-recommendations). Par rapport au fait que liste pourrait être n'importe quel type d'objet, je suis d'accord, mais il me semble que le problème reste le même. L'utilisation de len sur certains objets poserait d'ailleurs une erreur (len(None) par exemple), donc il faudrait de toute façon s'assurer au préalable d'avoir le bon type de données pour éviter ce problème. En tout cas, je comprends le débat qu'il peut y avoir et dans un cas comme dans l'autre ce n'est pas dramatique, personnellement je n'ai jamais eu aucun soucis dans mes scripts et ceux de mes collègues en utilisant le "truth value testing" qui fonctionne pour tous les types natifs et qui permet d'alléger le code. Merci en tout cas pour tes réflexions et au plaisir !
Petite question pour la correction 1, n’était il pas envisageable de passer par un switch case? Il faut que la version de python l’accepte bien entendu 😊
Ça existe depuis la version 3.10 (match case mais c'est le même principe que switch case) Dans le cadre de cet exercice, il arrive dans la formation après la présentation des structures conditionnelles. D'où leur utilisation dans ce contexte. L'utilisation des match case pourrait fonctionner également, après je ne pense pas qu'il y aurait une énorme plus-value dans cet exemple.
@@Docstring vue le petit nombre de cas et le fait qu'ils soient tous contigus (dans la range 1-5) ça devrait pas avoir beaucoup d'impact sur les perf (en considérant que c'est implémenté dans python via un switch C et que c'est pas une feature totalement interprétée) Je connais très peu python, mais en C, le switch va surtout être avantageux quand il y a beaucoup de cas, ou alors quand les cas ne sont pas contigus (1, 9, 17, 22, 36 par exemple). Ca m'es aussi déjà arrivé de préférer un switch pour exploiter le falltrough. Pour pousser la réflexion, pour cet exercice, je pense que (si ça existe en python) un tableau de fonction aurait été plus adapté qu'un switch (bien que probablement hors sujet vis-à-vis du but de l'exercice qui vise clairement à faire comprendre les structures conditionnelles).
Oui ça marche aussi ! C’est peut-être juste moins explicite. Avec le else tu peux avoir des effets de bords non prévus dans certains cas. Si tu sais vraiment la condition dans laquelle tu veux exécuter l’action, autant la mettre de façon explicite. Le else est quand même plutôt à privilégier pour toutes les autres actions que tu n’aurais pas prévues.
j'ai réalisé un programme avec factorisation du code je ne sait pas ou le poster pour que tout les abandonnés en profite après correction de ce code de votre pars
Salut ! Tu peux le poster directement ici, sinon dans un Gist pour qu'on ait un meilleur affichage, ou tu peux nous rejoindre sur le serveur Discord :)
Attention, 40:26 ce code : if not choice.isdigit() and int(choice) > 1 : print("Invalid") else : print("Valid") ne donne pas le même résultat que celui là : if not (choice.isdigit() and int(choice) > 1) : print("Invalid") else : print("Valid") Pour s'en convaincre on peut tester avec choice = "test" ou encore choice = "0" En réalité, la négation agit comme ça : non(A et B) = non(A) ou non(B), le "et" devient un "ou"
Bien vu Adam, je suis allé vite sur cette partie, c'est la loi de De Morgan, et effectivement ça ne fonctionne pas du coup. Désolé pour l'imprécision !
J'ai oublié de le mentionner mais cet exercice arrive à un moment dans la formation où les fonctions n'ont pas encore été vues. Et le projet revient par la suite avec différentes approches notamment une approche orientée objet. J'aurai l'occasion donc de faire d'autres vidéos sur le sujet avec ces exercices et je prendrai soin de mentionner ces précisions qui ont leur importance.
Non, je compte bien montrer une version de ce script avec les match case :) après historiquement je l'avais fait avec le classique if else et je pense que ça reste un exercice sympa pour mettre en pratique les structures conditionnelles
Une petite recherche sur google et tu as la réponse :) Sur Mac : option + shift + flèche du haut / bas. Si tu es sur Windows ou Linux... je te laisse faire tes recherches ;)
Idéal... difficile à répondre, ça dépend de beaucoup de choses, notamment de quel langage tu parles (j'imagine Python ?) Mais django / flask sont des incontournables avec Python.
j'arrive pas a comprendre pourquoi , alors que tout est écrit en Français, vous nous emmerdez a rajouter des "user input " etc , arrêtez avec l'anglais surtout quand ce n'est pas obligatoire !!! merci
Désolé mais le milieu du développement est très majoritairement anglophone. Il est conseillé par les développeurs de Python d'écrire en anglais même si l'équipe ne l'est pas pour faciliter la collaboration. Vous pouvez faire le choix de tout écrire en français mais force est de constater que pour les gens qui travaillent en entreprise, ça n'arrivera jamais. Donc autant s'habituer tout de suite. Donc si, désolé mais dans le contexte d'être développeur, l'anglais est obligatoire.
le plus gros soucis de ton code, c'est l'ingérence des actions sur ton objet application : en temps normal les champs liste et is_running sont en privé et des méthodes sont disponibles (dans la classe application) pour pouvoir les manipuler indirectement => il faudrait donc des méthodes add, remove, list, clear pour manipuler la liste ... et une méthode exit pour toucher le flag is_running autre point : le franglais ! ne mélange pas les 2 langues ! je vois ca sur les noms des variables (liste et is_running) et sur le message d'erreur de safe_int_input en anglais qui sort de nulle part ("Clear la liste de course", sérieusement ?) la ligne 61 présuppose que tu utilise select_element pour supprimer un élément, alors que son role est simplement de lister et choisir un élément de la liste (et c'est un truc que l'application doit proposer) => il faut donc déplacer la ligne 61 et l'intercaler entre la 69 et 70
