Ce serait peut-être l'occasion de revenir sur la philosophie qu'adopte Python par rapport au type (duck typing). Suivre le raisonnement suivant par exemple :
« Moins que le C », c'est pas un qualificatif que j'utiliserais. Le C a la réputation d'être fortement typé par son typage statique sans inférence, mais il permet de faire n'importe quoi avec ces types (bien plus que Python).
Les annotations + mypy apportent à Python un typage statique, mais on reste dans le même esprit qu'avant (plusieurs objets peuvent être du même type sans être les instances d'une classe commune).
Le terme « duck-typing » étant surtout associé au typage dynamique, on parle alors plutôt de typage structurel (à la manière des langages fonctionnels), avec des types comme Iterable[Text] par exemple.
« Moins que le C », c'est pas un qualificatif que j'utiliserais. Le C a la réputation d'être fortement typé par son typage statique sans inférence, mais il permet de faire n'importe quoi avec ces types (bien plus que Python).
Les annotations + mypy apportent à Python un typage statique, mais on reste dans le même esprit qu'avant (plusieurs objets peuvent être du même type sans être les instances d'une classe commune).
Le terme « duck-typing » étant surtout associé au typage dynamique, on parle alors plutôt de typage structurel (à la manière des langages fonctionnels), avec des types comme Iterable[Text] par exemple.
Le C a la réputation d'être fortement typé par son typage statique sans inférence, mais il permet de faire n'importe quoi avec ces types (bien plus que Python).
Juste pour dire : disons que le langage te le permet parce qu'il est basé sur l'idée que le programmeur sait ce qu'il fait et qu'il ne faut pas l'en empêcher. Pour autant, la plupart de ces pratiques sont proscrites (comprendre : ne sont pas définies et donc doivent être proscrites) par la norme du langage. Donc oui, on peut faire « n'importe quoi », mais en théorie tu n'es censé le faire que dans des cas spécifiques et lorsque tu sais ce que tu fais.
Sans vouloir lancer un troll, je pense que le typage, en tant que tel, est une vraie fausse problématique.
On aura toujours d'un côté des gens qui veulent un système de types qui leur donne toutes les garanties de la terre, et de l'autre côté des gens pragmatiques que ça empêche de bosser.
Dans ces conditions je ne pense vraiment pas que ça vaille le coup de passer des plombes sur le système de types de Python. Ni même d'un langage X ou Y. Comme le rappelle Taurre, le système de types n'est rien sans la philosophie du langage : un langage est fait pour coller à (et même renforcer) une façon de penser, pour donner un résultat tout en satisfaisant un jeu de contraintes bien défini. Le système de types du langage n'est qu'un élément parmi d'autres qui permet d'aller dans ce sens : en ce sens comparer des systèmes de types (disons celui de C et Python) sans tenir compte du contexte dans lequel ils sont mis en oeuvre est absurde. Typiquement, C et Python sont tellement distincts l'un de l'autre que ca ne fait aucun sens de comparer leur typage : on ne développera jamais un driver de périphérique en Python tout comme il serait débile d'écrire un bot IRC en C.
On aura toujours d'un côté des gens qui veulent un système de types qui leur donne toutes les garanties de la terre, et de l'autre côté des gens pragmatiques que ça empêche de bosser.
Faudrait pas trop généraliser non plus. J'ai perdu beaucoup de temps à cause du typage de Python, sur des problèmes qui me seraient jamais arrivé si j'avais fait ça avec un langage du genre OCaml. Perso ce qui m'empêche de bosser c'est quand j'ai une erreur de typage après plusieurs heures d'exécution
Ça serait pas mal qu'on puisse élever le débat au-dessus des avis tranchés de ce type.
On aura toujours d'un côté des gens qui veulent un système de types qui leur donne toutes les garanties de la terre, et de l'autre côté des gens pragmatiques que ça empêche de bosser.
Faudrait pas trop généraliser non plus. J'ai perdu beaucoup de temps à cause du typage de Python, sur des problèmes qui me seraient jamais arrivé si j'avais fait ça avec un langage du genre OCaml. Perso ce qui m'empêche de bosser c'est quand j'ai une erreur de typage après plusieurs heures d'exécution
Ça serait pas mal qu'on puisse élever le débat au-dessus des avis tranchés de ce type.
Cette phrase ne portait pas à débat. Ta reponse indique juste que tu es plus proche de la première catégorie (et en pratiquement une décennie de carrière je ne suis jamais tombé dans le cas que tu décris, donc j'appartiens à la seconde). Mais ça n'était absolument pas le sujet de mon post.
Les préférences des gens reposent sur leur façon de bosser. Et leur façon de bosser sur leur façon de réfléchir. À partir de là, débattre de quel système de typage est le meilleur, c'est chercher à faire rentrer les gens dans un système de pensée unique. Je considère donc que c'est un non-débat et que tout le monde devrait se montrer suffisamment ouvert pour simplement accepter l'idée que son langage préféré n'est qu'une extension de sa façon de bosser.
Typiquement, si je maîtrise suffisamment mon sujet pour faire ce que je veux en Python tout en structurant mon code et ma pensée de façon à ne jamais prendre de risques sur le typage (et plus précisément si je connais suffisamment mon boulot pour mesurer et désamorcer rigoureusement les risques que je prends parfois pour gagner du temps) je ne vois aucun intérêt à ce qu'un langage m'impose un carcan pour résoudre un non-problème : je veux pouvoir prendre des risques pour réagir à une urgence ou arracher un quick win quand j'en ai besoin, c'est mon métier. Je conçois tout à fait que d'autres ne sont pas câblés comme moi et préfèrent que le système de types les tienne par la main, mais pas qu'on veuille l'imposer en martelant que c'est "objectivement le mieux" : je suis suffisamment ouvert pour avoir tenté l'expérience de nombreuses fois, et à chaque fois cela a plus nui à mon confort et mon efficacité qu'autre chose.
Alors comme je suis sympa, je laisse une porte de sortie neutre : peut-être que ce que je developpe est assez différent, et a des contraintes suffisamment distinctes de ce que ces gens développent, j'accepte même avec un petit sourire bienveillant qu'on me dise que les clients de ma boite sont probablement peu exigeants en termes de qualité et de garanties (ce qui colle assez mal à l'image que j'ai de la Société Générale, de General Electrics ou de BMW, mais admettons), pourvu que le prosélytisme en face s'arrête là.
Tu noteras que bien que je préfère utiliser un système de types fort à titre personnel, ce n'est pas moi qui ai fait du prosélytisme en accusant les fans du typage fort d'être des idéalistes complètement déconnectés de la réalité tout en insinuant que le choix pragmatique est le typage faible, ce que tu pourras aller faire remarquer à certains industriels qui utilisent OCaml.
À un moment il faudra vraiment éviter de tomber dans l'exagération et reconnaître qu'au final c'est préférence personnelle+besoins du projet.
À un moment il faudra arrêter de chercher des insinuations dans un post où il n'y en a aucune. Mais si tu as un problème personnel avec moi (et vu l'interprétation que tu as choisi de faire de mon post, je commence à croire que c'est le cas) allons le régler en MP.
À quel moment j'insinue qu'il y a un et un seul choix pragmatique ?
À ce moment-là.
On aura toujours d'un côté des gens qui veulent un système de types qui leur donne toutes les garanties de la terre, et de l'autre côté des gens pragmatiques que ça empêche de bosser.
Tu introduis une opposition forte (d’un côté / de l’autre) entre programmeurs pragmatiques et programmeurs adeptes d’un typage fort. Mais si tu veux renier tes propres propos, n’hésite pas.
À quel moment j'insinue qu'il y a un et un seul choix pragmatique ?
À ce moment-là.
On aura toujours d'un côté des gens qui veulent un système de types qui leur donne toutes les garanties de la terre, et de l'autre côté des gens pragmatiques que ça empêche de bosser.
Tu introduis une opposition forte (d’un côté / de l’autre) entre programmeurs pragmatiques et programmeurs adeptes d’un typage fort. Mais si tu veux renier tes propres propos, n’hésite pas.
Je qualifie les seconds de pragmatiques, parce que leur approche favorise un certain pragmatisme (le fameux practicality beats purity de Python) mais à aucun moment cela signifie que seule leur approche est pragmatique et encore moins que les premiers sont idéalistes. Ça, c'est vous qui décidez de le voir dans mes propos.
PS : je vais donc me répéter : si vous tenez tant que ça à poursuivre ce troll et à vous offusquer de tout ce que j'écris, allons nous défouler en MP. Ça fera du bien à tout le monde.
Je suis un débutant avec Django, mais je suis sûr un projet pour un ami et je compte le déployer sur AWS avec Docker. Est-ce que, vu comment j'ai 27.000 sources, ça intéresserait des gens un article sur le déploiement d'une instance toute bête avec Docker / Gunicorn / ngix sur AWS ?
vous parlerez des websocket, de WAMP, autobahn et crossbar.io ?
Des nouvelles idées ou personnes interessées par le developement de jeux interessants sur python?
Que pensez vous d' un remake d'un petit jeu sympa des années 90 ? D'une revue de code d' un laureat pyweek ?
Étant donné que, vendredi, j'ai pu finir de configurer mon projet utilisant Django, je pense que d'ici peu de temps, une semaine ou deux, je vais démarrer la rédaction d'un article sur le déploiement avec Docker, nginx, Gunicorn et supervisor. J'en ai pas mal bavé alors autant que j'explique aux autres ce que j'ai compris.
Déployer sur AWS, je ne sais pas si j'aborderai, parce que bon, une fois que le conteneur est prêt, le déploiement ça dépend juste du cloud, donc c'est pas forcément très intéressant.
Connectez-vous pour pouvoir poster un message.
Connexion
Pas encore membre ?
Créez un compte en une minute pour profiter pleinement de toutes les fonctionnalités de Zeste de Savoir. Ici, tout est gratuit et sans publicité.
Créer un compte
