10 raisons pour lesquelles je suis toujours marié à Python


C’est une chance d’avoir un métier qu’on aime. Et l’avantage, c’est qu’on se sent l’énergie d’essayer plein de choses. J’ai codé (à plus ou moins grande échelle) en de nombreux langages : VB, C, C#, Java, Ruby, PHP, Javascript, Lisp, Bash, Erlang, SQL et leurs dérivés (langages générateurs, surcouches, etc).

Et j’en ai apprécié beaucoup. Ils m’ont fait découvrir des choses, on fait de moi un meilleur professionnel. Et m’ont donné des tas de perspectives sur mon métier, sur la résolution de certains problèmes, sur la philosophie de dev…

Je continue à utiliser d’autres langages au quotidien pour diverses tâches, j’ai remarqué qu’un marteau était beaucoup plus pratique qu’un tourne-vis pour enfoncer des clous, mais quand j’ai le choix, je reviens toujours à Python.

Et en voici les raisons.

Python est installé par défaut presque partout.

Que ce soit sur ma bécane Ubuntu, le Mac de Max ou un serveur CentOs, Python est installé par défaut dessus. Il n’y a rien à faire.

Bien entendu, il y a les traditionnels problèmes de version, d’installation de package, etc. Mais c’est vrai pour tous les langages.

De plus, quand Python n’est pas installé (Windows, Android…), il y a des programmes tout prêts pour le faire.

Et il tourne vraiment sur n’importe quoi, même sur des trucs super exotiques.

Python n’a pas besoin d’un IDE

On peut programmer en Python avec un simple éditeur de texte à coloration syntaxique. Le langage est tellement épuré et léger qu’il se passe complètement d’outils complexes comme Eclipse ou VisualStudio, Komodo ou Bean, et l’expérience est déjà confortable.

Évidemment, on peut utiliser un IDE, mais au final, je préfère même m’en passer et rester sur un éditeur de texte avancé comme Sublime Text.

Python est là depuis longtemps, et pour longtemps

Python est un langage très ancien (1990). En fait, contrairement à ce que l’on peut imaginer, il est apparu avant Java (1995). Il y a donc beaucoup d’expérience derrière ce langage et son environnement, et surtout, c’est la preuve qu’il est capable de tenir la longueur.

Comme Python est un des 3 seuls langages autorisés en production par Google (avec le C et le Java) mais aussi d’autres gros projets comme Dropbox ou Reddit, on peut être rassuré sur son avenir.

Python vient avec piles incluses, et un vaste jeu de piles de rechange

En fait, avec l’installation de Python, par défaut, il y a des modules pour tellement de choses que je continue à en découvrir après 10 ans de pratique.

Et quand il n’y a pas de libs installées par défaut, bah, on a pypi, et ses 22 mother fucker milles libs open source installables avec pip.

Et il a des perles.

Envie d’un serveur Web qui tienne la charge d’un site moyen sans rien installer (pas de Nginx, pas de compile, juste un fichier Python à poser) ? Cherrypy est votre ami.

Besoin de faire des traitements scientifiques de haut niveau ? Scypy est là pour ça.

Manipuler des images ? Pillow à la rescousse.

Mettre en place un serveur Web asynchrone ? Tornado ne demande même pas de compilation.

Manipulation de paquets, outils de déploiement, gestion de processus, contrôleur USB, créer un jeu vidéo, manipuler de l’argent, utiliser le format PDF, télécharger une vidéo de youtube, poster sur Twitter ou même crawler un site entier

Python ne se limite pas à X ou Y, et particulièrement comparé à la plupart des langages de scripting, Python ne se limite certainement pas à faire des sites Web ou de l’admin système.

Python me limite très rarement (ça arrive, par exemple pour l’embarqué). Je ne me pose pas souvent la question de ce que je peux faire, mais plutôt de ce que j’ai envie de faire.

Python est fair play

Les créateurs du langage n’avaient en aucun cas envie de rentrer en compétition avec les langages existants. Pour cette raison, Python est très ouvert sur l’extérieur et travaille très bien avec les autres langages et technologies.

On peut intégrer l’interpréteur Python dans son propre programme, et carrément ajouter le langage comme système de scripting (ce que fait Blender) ou plugin (ce que fait Sublime Text).

On peut appeler du code C ou Fortran depuis Python ou du code Python depuis Java ou .net.

Bref, Python n’est pas dans l’opposition, il est dans la collaboration. Ajouter Python à sa boîte à outil, c’est avoir un copain en plus.

Python force la lisibilité

Par sa syntaxe avec très peu de mots-clés et l’absence de blocs anonymes (les lambdas sont inlines), il est bien plus difficile (mais pas impossible ^^) de faire du code obfusqué en Python.

Écrire du Python sale est bien entendu toujours possible – et pratiqué – mais même du Python crade est plus lisible que beaucoup de code propre dans d’autres langages.

En forçant l’indentation, feature parfois détestée mais que je considère comme une des plus grandes forces du langage, Python limite la casse et permet de très facilement naviguer dans le code d’autrui et de s’y retrouver. Le logiciel libre en Python, c’est beaucoup plus facile.

La communauté Python possède une forte culture de la lisibilité (PEP8 \o/) et cela se sent dès qu’on veut travailler avec quelqu’un d’autre.

Python me fait gagner du temps

Pas de compilation, un typage dynamique, une syntaxe succincte, un debugger intégré, un shell de tests et des stack traces très verbeuses. Le langage a été inventé pour la productivité.

C’est très simple, quand je code dans un langage qui ne possède pas certaines de ces fonctionnalités, j’ai l’impression de faire une randonnée avec un boulet au pied.

Ayant expérimenté des langages avec et sans typage statique, je le dis tout haut, le temps que ça fait gagner en debugging ne rentabilise pas les contraintes que ça apporte (par contre niveau perf c’est sûr, c’est cool).

Mais même le design de Python a été pensé pour aller plus vite : design patterns intégrés (iterateurs, decorateurs), duck typing, unpacking, paramétrage dynamique, listes en intention, générateurs… Toutes ces petites choses qui cumulées vous font gagner des minutes, qui deviennent des heures.

Il y a de la doc

Je n’ai jamais rencontré de langages avec des docs parfaites (même si PHP a une excellente doc par rapport à la plupart des autres), en revanche j’en ai rencontré beaucoup avec de docs pourries, pas à jours, incomplètes, voire fausses.

En moyenne Python a une bonne doc, et en bonne quantité. Certes, il y des centaines de choses que je pourrai pointer du doigt, mais la documentation n’est pas un frein contrairement à de nombreuses technos hypes que je vois passer dans mon flux RSS.

C’est un corollaire des points précédents : Python est là depuis longtemps, et la communauté valorise le gain de temps. On le retrouve aussi dans la doc des projets tierce partie, qui sont souvent de bonnes surprises : celles de Django, scrappy, requests ont littéralement des milliers d’heures de travail.

On trouve même des livres gratuits, et en français pour apprendre Python. C’est assez incroyable de voir toute ce boulot mis à la disposition d’autrui.

Le fait que le langage soit autodocumenté et le code source facilement lisible rend aussi l’exploration très facile, et je vais très souvent voir sous le capot des libs que j’utilise.

Python est hackable

La nature dynamique de Python et son absence totale de mécanisme de sécurité énervent souvent des gens venant de langages plus stricts. Personnellement j’adopte la philosophie Unix autour de cela : ce n’est pas le rôle du langage de s’occuper de la sécurité, c’est celui de l’environnement.

Cela veut dire que si une lib que vous utilisez ne se comporte pas comme prévu, vous n’êtes pas forcément bloqué. Vous pouvez trouver une solution de contournement, très souvent sans toucher au code d’origine, afin de sortir la tête de l’eau le temps qu’un patch plus propre soit proposé et accepté.

Ça veut dire aussi que Python s’inscrit formidablement bien dans le cadre d’un développement agile : pas besoin de faire des plans sur la comète, vous pourrez changer facilement d’avis en cours de route.

Python me rend heureux

C’est très subjectif, évidemment. Mais quand je code dans certains langages, j’ai mal au cul. Chaque ligne est taillée, extraite d’un bloc de granit et roulée jusqu’à sa place dans le fichier.

Quand je code en Python, certaines solutions me font sourire. Les problèmes sont résolus élégamment, les algos tiennent en quelques lignes claires, et je peux les changer facilement en cours de route.

Python n’est pas parfait, loin de là, il y a eu, et il y aura encore, ces fameuses nuits glaciales ou l’épuisement n’est tenu éloigné que par le délire de la confusion mentale, à la recherche de la raison de ce putain de bug, sur le déchiffrage de ce message d’erreur cryptique ou en train de préparer l’assassinat violent de l’auteur d’une lib qui a fait de la merde.

Mais globalement, Python, c’est comme le cochon.

58 thoughts on “10 raisons pour lesquelles je suis toujours marié à Python

  • foxmask

    t’as pas fait de PERL ? dude ! le langage dont tu fais des poemes en codant avec les verbes dudit langage ;)

    sinon un gros +1 sur tout ce qui a été clairement exposé.
    on en vient à ne plus rien avoir envie de troller :D

  • Sam Post author

    Mes quelques rencontres avec Perl m’ont vite détourné du langage. J’ai énormément de mal à la lire, et je ne me sens pas de passer des heures sur un langages qui est une corvée pour moi à déchiffrer.

  • Poulet

    J’ai beau les croiser régulièrement, je ne comprends pas les arguments en faveur du typage dynamique (qui est un abus de langage, en réalité on devrait probablement dire « absence de typage », car les types ont un contenu essentiellement syntaxique). En quoi est-ce une bonne chose de ne pas pouvoir compter sur le compilateur pour t’aider à débuguer ton code ?

    Je pars d’un principe simple : tous les programmeurs font des erreurs lorsqu’ils écrivent du code. Il y a peut-être des gens qui en font moins que d’autres, et qui écrivent aussi plus vite, mais tout le monde écrit du code bugué, ou du code qui devra être réutiliser par quelqu’un d’autre plus tard. Les types sont une forme de documentation et de spécification minimaliste, ils sont utiles à la fois au premier auteur du code pour s’assurer que ce qu’il fait a une chance de ne pas crasher à l’exécution, et aussi aux auteurs suivants qui feront évoluer le code.

    Tous les langages statiques ne sont pas forcément aussi verbeux et pénibles que Java. Aujourd’hui, on a des langages qui infèrent les types (mais qui sont statiquement typés néanmoins) et qui n’ont rien à envier, niveau expressivité, à Python. Dans ces langages, se plaindre qu’un compilateur refuse un code mal typé, c’est comme se plaindre qu’un code bugué provoque une erreur à l’exécution.

    De la même façon, je ne comprends pas qu’on dise que « ce n’est pas le rôle du langage de s’occuper de la sécurité ». Moi j’adorerais que mon compilateur soit capable de me dire « attention, faire ceci fragilise ton code, c’est probablement une mauvaise idée ».

  • dacrovinunghi

    Voila c’est ce que j’aime on indente pour quelque chose en double avantage stucture et lisibilité et peu de sucre syntaxique.

  • sil

    Y a moyen de s’abonner aux commentaires sans en poster (pas envie de déposer ma petite crotte à chaque article) ?

  • sil

    Y a-t-il moyen de s’abonner aux coms sans poster sa petite crotte à chaque fois ?

  • raphi

    Moi ce que j’aime avec les types en python, c’est que c’est dynamique, mais aussi fort.

    En PHP ou en js, si on fait un

    $var = 1 + '1'

    , on sait jamais si on va s’retrouver avec 2 ou “11”, et ca cause des erreurs bien relous. Après ca, j’comprend parfaitement les gens qui peuvent pas piffer les langages dynamiques.

    En thonpy, on s’mange une exception direct, et on est obligé de “caster” ses variables explicitement. Du coup, on retrouve en partie la sécurité des langages statiques, sans avoir a s’emmerder a tout déclarer explicitement. A mon avis, the best of both worlds.

    PS: C’est la première fois que j’prend la peine de commenter ici, mais je suis le blog depuis un petit moment, et j’tiens a dire bravo, c’est fun, très intéressant et j’apprend plein de trucs, et en plus voir la tronche de sam & max ca fait toujours plaisir au fan des flics en freelance que je suis ^^

    PPS: C’est rigolo le trombone relou qui detecte les posts trollesques, mais sachant qu’il est apparu alors que je n’avais tapé que deux lignes, je m’demande ce qui a bien pu le réveiller, c’est “PHP” qu’il aime pas ^^ ?

  • golgotha

    Que dire de plus… Python est une des raison qui fait que j’adore Django, un des langages dont on tombe amoureux : moi j’ai craqué sur son irrésistible compréhension de liste :)

  • Rumsteak

    @Poulet : tout programme de prod sérieux étant couvert par des tests unitaires (mention Bien bonus si il est codé en TDD), que le langage soit dynamique ou pas, au final tu te fieras à eux. Si les tests passent, tu seras autant en confiance que ce soit du Java ou du Python/Ruby.

  • Sam Post author

    @Poulet:

    Le typage dynamique VS typage statique est une vieille guerre dont je ne vais pas nourrir le troll. Disons simplement que je comprends ton point de vue mais que j’ai également des de bonnes raisons d’aimer le typage dynamique (qui reste un typage fort en Python, car il y a bien typage), notamment le duck typing, l’absence du besoin d’interface, la légèreté du code et le fait qu’on ai pas besoin de gérer des détails comme le boxing / unboxing, etc. Je dis cela après avoir tester des langages tels que Go ou D.

    @sil: il y a un lien “flux rss des commentaires” en bas de chaque colonne de commentaires.

    @raphi : +1. Et oui, il réagit sur certains mots clés comme PHP car cette mesure nous permet de … Nan, c’est juste pour le fun en fait.

  • Rumsteak

    Sinon pas mal comme article, en tant que Ruby fanboy je me suis quand même retrouvé sur pas mal de points. Même si si Ruby est moins “piles incluses” et qu’hors du web et des scripts, il est assez peu présent.

    Ca ne m’empêche pas de suivre régulièrement ce blog où j’adhère beaucoup à la philosophie des auteurs. Je le vois plus comme un bon blog français sur le scripting/unix en general.

    De toutes façons un bon dév a généralement codé dans plusieurs languages différents (il faut au moins un fortement typé, un langage de script, et un fonctionnel) pour élargir sa compréhension. Apres le langage fétiche de chacun c’est les goûts et les couleurs…

    Vive le polyglottisme informatique, les licornes et les bisounours, et aimez vous les uns les autres bordel de merde.

  • 01Ivier

    Le seul inconvénient personnel que j’ai trouvé à ce langage c’est qu’après 5 ans de pratique, je continue d’écrire pyhton pour lancer l’interpréteur…
    Je me suis fais exorciser deux, trois fois…
    Mais le truc persiste… :-/

  • Eric

    Merci,

    Je rajouterais une seule chose, Python est aussi lisible qu”un texte de Baudelaire, on respecte l’i(n)dentation et tout le monde peut le lire.

    Eric, j’ai toujours pas payé mon hébergeuse communiste.

  • Syl

    Pas mieux! Python, c’est de la bombe!

    Perso, le seul truc qui m’ait fait péter les plombs en Python (et ça m’arrive encore), c’est la gestion de l’encoding. J’ai lu votre super article sur le sujet, mais j’ai encore quelques erreurs.

    A part ça, j’ai jamais coincé très longtemps sur un bout de code…franchement, j’ai découvert python lors de mon stage de DUT, et j’en suis directement tombé amoureux!

    Le plus chiant avec le python, c’est quand on doit utiliser autre chose…là, c’est la déprime assurée! Mais bordel, elles sont où les listes en intention? Et c’est quoi cette syntaxe pourrie? Et pourquoi mon programme met 30 secondes à charger??

  • Syl

    @01Ivier: +1, j’arrête pas!! Faudrait vraiment que je fasse un alias moi aussi!

  • michel marcon

    Hello

    OK. Suis plutot Perl. Ta foi m’amuse. Mais je ne tiens pas aux guerres de religion. 8-)

    Que Python soit avec toi !!

    michel marcon (aka cmic)

  • Eylith

    J’trouve vraiment le Python dégueulasse à lire, c’est la raison principale pour laquelle je ne m’y suis pas encore mis. Peut-être que je ne suis tombé que sur des samples pourris ? Ou peut-être que ça vient avec l’habitude..

  • kontre

    Moi ce qui m’a le plus pris la tête au début, c’est le fait que la borne supérieure des intervalles soit exclue ! Avant je faisais pas mal de Matlab (indexation à partir de 1 et borne sup incluse), le passage à numpy a été douloureux de ce point de vue (l’indexation à 0 ça va, ayant fait du C j’avais l’habitude et je trouve ça au final plus logique).

    L’encoding, c’est venu qu’après…

  • Fred

    @Eylith : j’ai un pote qui a eu un peu la même réaction. En même temps, quand on a fait que du C/C++ et du Java, tout ce qui n’est pas à base de curly braces et de for (int i=0 ; i < nb ; i++) { … }, ça peut paraître bizarre.
    Et c'est vrai que quand on a l'oeil et le cerveau habitués à certains choix historiques, c'est pas forcément un avantage d'avoir affaire à des syntaxes plus naturelles pour l'être humain. Encore que, pour moi, le python est parfait à ce niveau là, mais, chacun ses goûts. Le "unless" de certains langages ne me convainc pas, par exemple.

  • elo

    “autorisés en production par Google … Dropbox ou Reddit … on peut être rassuré sur son avenir.”

    Heu, c’est tout sauf rassurant. Tu parles de sociétés commerciales qui n’hésitent pas à fermer des services non rentables.

    Microsoft a bien tué VB6 alors que c’était un langage très utilisé, très puissant, utilisé dans Office via le VBA.

    Après, Pyhon, j’ai essayé mais ça ne m’a pas fait sauter au plafond. Je préfère le C++ (celui de Borland), un vrai langage d’homme, ça. Ou le JS (le vrai, le pur, pas celui des jquery).

  • Etienne

    C’est clair que l’habitude joue un rôle prépondérant dans toutes ces histoires de préférences. Ce qui rends souvent difficile de discuter “objectivement” des avantages et inconvénients de tel langage (ou paradigme) par rapport à tel autre.

    Cela dit, je ne suis pas partisan du Dieu Unique. Je préfère les polythéismes. C’est plus ouvert à la diversité. Plus sain.

    Malgré tout je pense qu’avec un peu de bonne foi on ne peut pas nier que python est le meilleur langage de tous. D’ailleurs on devrait abandonner tous les autres.

  • Etienne

    @Sam

    Prochain post:
    “10 raisons pour lesquelles je ne suis toujours pas marié”

  • Etienne

    T’es marié à python!

    Les femmes dans nos contrées acceptent mal la polygamie. Les hommes mariés en témoigneront….

  • Manu

    Ah c’est marrant, à propos de la doc, en tant que dev principalement PHP, j’ai souvent admiré la doc des autres langages…

    En tout cas, ça donne envie d’approfondir avec Python..

  • tarzan

    Écrire du Python sale et bien entendu toujours possible – et pratiquer – mais même
    =>
    eSt […] pratiquÉ

    (à effacer après correction)

  • Quasar

    Très bon article ! Ça fait pas si longtemps que ça que j’ai découvert votre blog, et c’est juste excellent !

    Vive Python !

    (et accessoirement la section cul, mais faut pas le dire !)

  • Kromak

    Cela fait maintenant quelques mois que je me dis qu’il faudrait que je me mette à Python, que ça ‘apporterais beaucoup, autant sur le plan personnel que professionnel…

    Et en lisant ces qq lignes, ça me donne encore plus envie de m’y mettre !

    (je n’aurais jamais soupçonné que python était si vieux…)

  • Jerome

    Bonjour
    Je découvre python et j’ai jamais codé… ca fait un peu intro alcoolique anonyme mais j’aime bien.
    Et une question brule mes jeunes lèvres noobesques, y a t il une méthodologie pour développer “propre”:
    – faut il faire des schémas qui impressionnent les geek mais peu les filles type mcd ?
    – prévoir un outils qui automatise une doc sur la base des commentaires
    – doit on exploser tout le code avec les fonctions dans un fichiers et les autres dans le fond à droite…

    Bref y a t il une méthodo gloable pour “bien faire” (analyse, coding, test….) ?
    D’avancer merci et bravo pour le blog
    (ca démystifie largement l’image reloud du programmeur… ouhhh le vilain mot)

  • Sam Post author

    Hello Jerome,

    Pour écrire du code propre, il faut utilise un mélange de règles, d’expérience et d’exposition.

    Les règles, ça mérite un article à elles toutes seules, et je le rajoute dans les idées…

    L’expérience, ben, faut coder.

    L’exposition, c’est juste avoir un maximum de retour sur ton code par les autres. Leur retour du passé t’aideront dans le future, mais même quand tu es à l’aise, s’exposer tout de suite aide beaucoup.

  • Thot

    Salutations !

    J’ai découvert votre blog il y a peu de temps et j’y adhère complètement (dommage que la partie cul soit exclusivement hétéro mais je comprends bien que l’inverse ne serait pas forcément un bon point pour votre lectorat ha ha), franchement c’est agréable à lire, c’est bien écrit, c’est frais et surtout : ça parle Python, mon premier langage de programmation. ^^

    On m’a dit tout et son contraire sur ce langage : c’est le premier à apprendre de par sa simplicité d’approche et son apprentissage rapide mais on me l’a aussi déconseillé en tant que premier langage car de trop haut niveau, ne me permettant pas de tout comprendre (comme le ferait par exemple un C ou un C++).
    J’ai maintenant bien entamé les cours sur Python (en autodidacte) et je m’éclate, j’espère donc que ça va continuer !
    Personnellement, je suis passionné par l’intelligence artificielle depuis longtemps et j’aimerais si possible allier ce domaine avec Python pour bosser sur des projets en ce sens (les perspectives donnent le vertige tant c’est fascinant). Vous pensez que Python est approprié pour la recherche scientifique (dans cette voie-là) ?
    Au pire, je me pencherai sur le C++ mais je suis déjà amoureux du langage de Guido van Rossum donc bon, ça me ferait chier…

    Longue vie à vous et à ce blog en tout cas, et vive Python !

  • Sam Post author

    Python est très très utilisé dans la recherche scientifique, c’est probablement le domaine sur lequel on ne peut pas se tromper. Mais ça n’empêche pas d’apprendre le C ou C++, ce sont des langages complémentaires à Python.

  • Thot

    Cool ! Merci de ce renseignement précieux.

    Je pense que je vais continuer mon apprentissage de Python et dans un second temps, j’irai voir du côté du C/C++ afin de parfaire mes connaissances.

    PS : vos avatars (toi et Max) sont tirés de la même BD ? J’aime le coup de crayon. ^^

  • Thot

    Moment de solitude…
    Oui, ce sont les personnages de la franchise Sam et Max quoi ! Ceci explique cela. Je sors.

  • Selso

    Bonjour,

    Globalement d’accord : python est riche en bibliothèque pour maquetter.

    Je rejoins certains commentaires concernant le typage dynamique.
    Si c’est très pratique lors de la production, c’est un enfer pour la maintenance car toutes les mauvaises pratiques sont possibles avec cela.
    Le typage dynamique ôte toute discipline sur le retour de fonction et l’on se retrouve souvent embêtés sur les retours de fonctions dont le contenu peut varier.
    J’ai passé dernièrement des heures à décoder un srcipt python pour comprendre quelles données sont générées sur les appels de méthodes. Et je me rends compte que suivant la nature d’une information traitée, je reçois une liste ou un tuple, avec une structuration du contenu qui peut varier.
    Alors je pense que mon expérience python fait que je maitrise mal le flot de données, mais je crois aussi que le développeur à fait un peu n’importe quoi avec ce qu’il génère.
    S’il avait décrit une structure à remplir dès le départ, il aurait plus facilement homogénéiser sont traitement et le compilo aurait pu l’aider pour cela (voir même dès qu’il code en ligne avec un bon IDE).

    Je code en C depuis plusieurs années et je me rends compte que dans certains cas un typage auto ou dynamique améliorerait la productivité (ex : une variable locale retourné par une fonction pourrait automatiquement prendre le type de celle-ci).
    Mais cela doit rester un usage parcimonieux.

  • Sam Post author

    Plusieurs personnes m’ont reporté cela, mais je n’ai jamais eu ce problème moi-même. J’ai du mal à imaginer comment on peut être inconsistant sur les valeurs de retour qu’on écrit soit-même.

  • Selso

    C’est là qu’un bon IDE pourra aider à :
    * détecter des erreurs de typographie sur des noms de variables (problème qui peut s’élargir à d’autres problèmes que python).
    * Vérifier une homogénéité du retour des fonctions, compléter un manque de documentation sur ces dernières.
    * faire passerelle avec la très riche documentation des modules python
    * proposer du profiling de code
    * déployer avec py2exe,
    * etc…

    J’ai par ailleurs déjà été bien surpris sur la complexité des instructions python du fait de leur possibilité étendue sur la manipulation des containers. Ca ressemble vraiment à des expressions régulières, du one-shot qui marche du tonnerre mais quasi impossible à reprendre.

  • Max

    @olivier & @syl

    Moi je pense à ma première cops.

    py-THON

    impossible de se gourer, la mnémotechnique est la clef du succès.

  • A. Gusteau

    Alors que je cherchais un comparatif sur les langages de scripts, je suis tombé par hasard sur cette page. Et cet article m’a diablement donné envie de tester le Python !
    Par ailleurs, à la fin de ma lecture, intrigué par l’onglet “Cul” qui crée un contraste saisissant avec “Admin Sys”, je navigue un peu sur vos articles… Et quelle belle surprise ! un mélange détonnant de culture, fun, réflexions décomplexées, et d’expertise ! Bravo messieurs, ce site est une totale réussite.
    Ce sont des personnes comme vous qui redonnent au terme “informaticien” ses lettres de noblesse.
    En un mot, Je kiffe.

  • Franck

    Bonjour, quels sont d’apres vous les tutos les plus pedagogues pour un débutant. Merci.

  • Tim

    Sur la forme : ‘bloc de granit‘.

    Sur le fond : tout est bon. Y compris la subtile précision de Sam en réponse à Poulet : Python est effectivement fortement typé, mais typé (une fois pour toute) uniquement à l’exécution du code.

    Et pour faire le lien entre le sujet du typage et celui de la responsabilité du langage, j’invite à découvrir le leitmotiv des codeurs Python – “we are all consenting adults here” – au travers de cet échange sur une mailing list Python.

  • Yannick

    Je plussoie.

    Pour le peu que je connais Python, une SEULE chose me manque un peu, la notion (“élégante”, en évitant 30 lignes de code) de constante.

  • Jacti

    Franchement, est-ce que quelqu’un ici se risquerait à coder en Python du guidage de missile ou le pilotage d’une centrale nucléaire ? Un langage à typage dynamique me paraît loin d’être le meilleur choix pour ce genre de logiciel. Je dirais même que c’est à bannir !

    Il n’existe pas de langage à tout faire, y compris Python.

  • Sam Post author

    Un guidage de missile non car il faut du temps réel. Un pilotage de central nucléaire oui car la lisibilité de Python, le nombre de libs éprouvées et robustes disponibles et l’absence de corruptions de mémoire possibles en font une excellente solution. D’autant qu’avec mypy on peut maintenant vérifier le typage de Python pour les projets qui ont besoin de plus de gardes-fou.

    Pour cette raison, il est utilisé par la NASA : https://www.python.org/about/success/usa/, le Centre National d’Etude spatial et le Commité de l’Energie Atomique. J’ai eu le plaisir de former à Python des gens travaillant dans les deux dernières structures :) Si il y en a qui nous lisent, coucou !

    • Tim

      Je me permets de nuancer que le temps-réel, Python le fait très bien. Tout dépend de la contrainte :p

      Le guidage de missile aura surtout la contrainte de l’embarqué.

      Du temps-réel avec Python, j’en ai fait pas mal ces dernières années !

Comments are closed.

Des questions Python sans rapport avec l'article ? Posez-les sur IndexError.