00:00 <discord_afpy> <agnes1825> Je ne sais où il a vu qu'on ne faisait pas de POO mais c'est pas du tout le ressenti que j'ai eu quand j'ai commencé à faire du Django par exemple. Moi j'ai vu des classes hyper utiles qui permettent d'avoir un code ultra descriptif, des outils pour tester les vues aussi bien "fonction" que "classe" les doigts dans le nez, un système de dépendances qui permet de tout bien ranger
00:00 <alain_afpy> Inline C dans une fonction Python - https://discuss.afpy.org/t/inline-c-dans-une-fonction-python/2463
00:04 <discord_afpy> <agnes1825> En tout cas ce dont je suis sûre du haut de mes 15 ans d'XP c'est que ce ne sont pas forcément ceux qui sont les plus sûrs d'eux qui sont les mieux renseignés, ni les plus intéressants à écouter. 🤫
06:52 <discord_afpy> <eyecontrol> Apparemment il a 10 ans d’expérience en Python.
06:52 <discord_afpy> <eyecontrol>
06:52 <discord_afpy> <eyecontrol> Merci pour ton retour.
06:52 <discord_afpy> <eyecontrol>
06:52 <discord_afpy> <eyecontrol> Perso je ne pratique pas trop l’OOP (je ne fais pas de Django) et je n’ai pas l’impression que ça pose problème, même autour de moi, à ceux qui ont bien plus d’expérience.
06:52 <discord_afpy> <eyecontrol>
06:52 <discord_afpy> <eyecontrol> Mais je remarque que beaucoup de personnes ont des idées très arrêtées sur Python. J’avoue que c’est saoulant.
10:34 <entwanne> eyecontrol: En tout cas la POO n'est pas à opposer à l'aspect procédural, ce sont plutôt des concepts orthogonaux je dirais. Ce qui s'oppose au procédural c'est plutôt le fonctionnel (et encore il y a des langages qui combinent bien les deux) : mais la POO existe en procédural (C++, Java, Python, PHP, etc.) comme en fonctionnel (OCaml)
10:36 <discord_afpy> <fred.et.rick> bonjour
10:36 <discord_afpy> <fred.et.rick> > Apparemment il a 10 ans d’expérience en Python.
10:36 <discord_afpy> <fred.et.rick> si il a pratiquer Python de 89 à 99, ça peut se comprendre qu’il ai ce genre d’opinion.
10:36 <discord_afpy> <fred.et.rick>
10:36 <discord_afpy> <fred.et.rick> De mon coté, je ne comprend pas trop ce qu’il veux dire. je ne suis pas très très au fait de la programmation fonctionnelle, mais quand je veux utiliser les paradigmes les plus courants, j’ai tout ce qu’il faut dans Python. Pareil pour l’orienté objet, c’est un peu étrange en Python comparé à du java, c# ou php, mais ça reste tout à fait utilisable.
10:37 <entwanne> Le paradigme objet est tout de même au cœur de Python : en Python toute valeur manipulée est vraiment un objet (est une instance d'object, possède des attributs/méthodes) et tous les mécanismes du langage (protocole d'itération, callables, etc.) reposent sur des interfaces d'objets
11:13 <discord_afpy> <eyecontrol> Non il est plus jeune que moi et pratique encore Python en entreprise
15:03 <discord_afpy> <saturn7694> entwanne un des premiers languages à avoir intégrer la POO est common lisp qui est un des premeirs langage fonctionnel donc c'est pas forcément à opposé en effet
15:06 <discord_afpy> <saturn7694> opposer*
15:09 <discord_afpy> <saturn7694> le vrai reproche qu'on peut faire à Python qui sont aussi des forces c'est le typage dynamique et l'absence de variable privée. Sinon pour le reste c'est multi paradigme et c'est un très bon langage pour apprendre a programmer car ça permet de voir tous les pradigme, se concentrer sur l'algorithme sans trop se poser des question sur les détails d'implémentation
15:11 <discord_afpy> <saturn7694> le multi héritage aussi je comprends que ça puisse surprendre
15:18 <discord_afpy> <eyecontrol> Intéressant tout ça !
15:18 <discord_afpy> <eyecontrol> Merci 🙏
16:00 <discord_afpy> <fred.et.rick> > le vrai reproche qu'on peut faire à Python qui sont aussi des forces c'est le typage dynamique
16:00 <discord_afpy> <fred.et.rick> pas vraiment, depuis 3.6 (de mémoire), si tu veux du typage statique en Python, c’est dispo. Perso je n’utilise plus le typage dynamique depuis un bon moment
16:19 <discord_afpy> <saturn7694> tu veux dire les type hint ?
16:20 <discord_afpy> <saturn7694> c'est pas vriament du typage statique
16:21 <discord_afpy> <saturn7694> ce serait un sacré changement ça
16:29 <discord_afpy> <saturn7694> ça permet de palier au problèmes apportés par le typage dynamique. mais d'un autre côté c'est bien le typage dynamique dans certains contexte. à l'époque où j'ai commencé à apprendre python c'était vu comme un avantage. Après on s'est rendu compte que sur des gros projet c'était bien d'avoir un contrôle sur les types de données et qu'on a eu mypy pydantic etc... c'est assez recent en fait
16:29 <alain_afpy> Pour apprendre python vous pouvez commencer par ici: https://docs.python.org/fr/3/tutorial/index.html
16:34 <discord_afpy> <saturn7694> dans un langage a typage statique tu peux faire de l'inférence par exemple
16:35 <discord_afpy> <saturn7694> mypy et ts le font un peu c'est vrais aussi...
20:10 <discord_afpy> <fred.et.rick> À partir du moment ou l'analyseur de type t'interdit de changer le type à la volé, pour moi ça le devient^^
20:10 <discord_afpy> <fred.et.rick>
20:10 <discord_afpy> <fred.et.rick> Après ça reste un outils externe à mettre en place et tu peux tjrs faire sans, mais du coup, le typage dynamique nnest plus un problème
20:12 <discord_afpy> <fred.et.rick> On peu faire de l'inférence de type en C?
20:23 <entwanne> <saturn7694> c'est pas vriament du typage statique
20:23 <entwanne> C'est quoi alors ?
20:29 <entwanne> Souvent quand je lis qu'en Python mypy n'est pas à considérer comme du typage statique ça dit que c'est parce que c'est un outil à part, mais pour moi tant que ça rentre dans la chaîne de traitement ça compte. En C++ si tu ne considères que le fichier compilé il n'y a aucun typage, c'est un travail réalisé par un analyseur statique, qui est entre autres le compilateur
20:30 <entwanne> Le langage Python n'est pas statiquement typé, mais le sous ensemble Python-valide-mypy peut l'être
20:37 <discord_afpy> <fred.et.rick> entwanne: c’est aussi mon point de vue, tant que l’analyse statique est capable de te garantir que cette variable aura se type là à l’exécution et uniquement ce type la, à mon sens, c’est aussi statique que du C
20:43 <discord_afpy> <fred.et.rick> > à l'époque où j'ai commencé à apprendre python c'était vu comme un avantage
20:43 <alain_afpy> Pour apprendre python vous pouvez commencer par ici: https://docs.python.org/fr/3/tutorial/index.html
21:38 <discord_afpy> <saturn7694> bon je sais pas si on peut dire que C fait du typage statique. je pensais à des langages comme rust, haskell, scala etc...
21:40 <discord_afpy> <saturn7694> c'est un peu plus verbeux faut l'aider un peu plus
21:45 <discord_afpy> <saturn7694> mais ok je veux bien dire que ce n'est plus un problème. Bien que je ne sois pas sûr que l'on puisse avoir la même puissance pour les combiner même si il y a des union etc... et que je n'ai jamais pensé perso que ce soit un problème.
21:47 <discord_afpy> <fred.et.rick> pour le coup, même si le système de type a encore des trucs un peu frustrant en python, y’a plus de puissance pour les combiner qu’en PHP
21:48 <discord_afpy> <fred.et.rick> qui vérifie les types à l’exécution, donc la pour le coup, c’est statique de chez statique
21:49 <discord_afpy> <saturn7694> oui ok, je viens de vérifier ça j'étais pas sûr mais mypy implémente les types récursifs
21:49 <discord_afpy> <saturn7694> interéssant... https://mypy-lang.blogspot.com/2022/11/mypy-0990-released.html
21:50 <discord_afpy> <fred.et.rick> ah tiens, j’étais passé à coté de cette info, je vais pouvoir réécrire un type
21:51 <discord_afpy> <saturn7694> oui bon la récursivité en Python... (tiens j'aurais dû parler de ça aussi)
21:54 <discord_afpy> <saturn7694> bon là c'est sur des structures de données donc ça va j'imagine
21:54 <discord_afpy> <fred.et.rick> ça j’avoue, ne pas pouvoir résoudre tout les problèmes de l’advent of code avec de la récursivité, c’est un vrai crève cœur
21:56 <discord_afpy> <saturn7694> oui ça peut gêner. Mais TCO c'est juste une boucle while au final. ce que tu résous par un appel récursif peut toujours se résoudre avec une pile et une boucle. C'est juste plus verbeux et moins lisible
21:57 <discord_afpy> <fred.et.rick> tout à fait
21:58 <discord_afpy> <fred.et.rick> et en même temps, pour être honnete, c’est assez rare que je me prenne une RecursionError des cas de la vie quotidienne
22:03 <discord_afpy> <saturn7694> oui perso j'évite au maximum en python sauf si je sais que c'est pas trop profond mais c'est un risque quand même
22:03 <discord_afpy> <saturn7694> js est un peu plus permissif sur ça
22:12 <discord_afpy> <saturn7694> > À partir du moment ou l'analyseur de type t'interdit de changer le type à la volé, pour moi ça le devient^^
22:12 <discord_afpy> <saturn7694> ah on peut pas faire des trucs comme ça du coup (comme en ts):
22:12 <discord_afpy> <saturn7694> ```ts
22:12 <discord_afpy> <saturn7694> let x : A = y as unknown as A
22:12 <discord_afpy> <saturn7694> ```
22:12 <discord_afpy> <saturn7694> c'est pratique pour les TU
22:15 <discord_afpy> <saturn7694> oui je viens de vérifier . c'est peut être une bonne chose
22:19 <discord_afpy> <fred.et.rick> oui, tu peux dire à mypy de pas te faire chier et que connais mieux le boulot que lui, `x = cast(A, y)`, mais à partir de là, x sera toujours concidéré comme étant de type A, tu ne peux plus changer le type de x (sauf avec un `# type: tg-mypy`)
22:20 <discord_afpy> <fred.et.rick> mais bon, c’est un peu la base de python, on est entre grande personnes
22:25 <discord_afpy> <saturn7694> ah oui c'est la même chose. C'est surtout pratique pour mocker dans les tests faut pas l'utiliser sur du code en prod
22:26 <discord_afpy> <saturn7694> (je fais trop de js en ce moment...)
22:28 <discord_afpy> <saturn7694> c'est mieux cast c'est un peu con ce unknown... au début on voit pas trop la différence avec any...
22:57 <discord_afpy> <fred.et.rick> l’avantage avec pydantic, c’est que rien n’est unknown, sinon la validation échou^]
22:59 <discord_afpy> <saturn7694> pydantic c'est autre chose encore. non mais c'est la différence entre any et unknown c'est juste idiot. c'est quoi la diférence entre dire je ne sais pas ce que c'est et ça pourrait être n'importe quoi.
23:01 <discord_afpy> <fred.et.rick> dans un cas, tu accepte que le type puisse être différent d’une exécution à l’autre, dans l’autre, tu ne sais juste pas ce qui doit rentrer
23:02 <discord_afpy> <fred.et.rick> du point de vue de la machine, c’est pareil, du point de vue de l’humain qui lit le code, y’a des subtilités
23:04 <discord_afpy> <saturn7694> je vois bien la différence des deux. c'est juste comme c'est nommé c'est pas "beginners friendly"
23:05 <discord_afpy> <fred.et.rick> ah, sur ce coup là, je suis d’accord^^
23:07 <discord_afpy> <fred.et.rick> après, de manière générale, le typage, à par en C, j’ai l’impression que c’est pas du tout beginners friendly
23:08 <discord_afpy> <saturn7694> je pense que quand C est sorti ils en étaient pas du tout là surtout
23:08 <discord_afpy> <saturn7694> les types c'est une longue histoire
23:08 <discord_afpy> <fred.et.rick> en tout cas le typage tel que répendu en ce moment à grand coup de génériques et d’interfaces
23:09 <discord_afpy> <fred.et.rick> tout à fait
23:09 <discord_afpy> <saturn7694> c'est toute une théorie qui s'est éléboré en même temps que les langages
23:09 <discord_afpy> <saturn7694> élaborée*
23:11 <entwanne> Le typage structurel c'est sympa
23:11 <discord_afpy> <saturn7694> je ne sais pas exactement de quand date la théorie sous jaccente mais je ne pense pas qu'elle soit bien antérieure aux années 60-70.
23:12 <discord_afpy> <fred.et.rick> entwanne: oui, c’est sympa, mais quand t’essaie d’en abuser, tu te prend vite un retour de baton^^
23:12 <discord_afpy> <fred.et.rick> en tout cas en python
23:13 <entwanne> J'avais plus le Rust et l'OCaml en tête, mais ça pose quoi comme problème en Python (si on parle bien de Protocol) ?
23:15 <discord_afpy> <saturn7694> en ts je fais que ça perso je défini jamais de classe que des interfaces
23:15 <discord_afpy> <fred.et.rick> les IDEs on un peu de mal à suivre, du coup c’est pas nécessairement simple de lister ce qui, dans ton projet, va pouvoir rentrer dans ta fonction. ce qui n’est pas nécessairement un pb, mais des fois, ça rend le code difficile à maintenir
23:23 <entwanne> ah je n'utilise que mypy pour les vérifications