Entretien avec des développeurs Python francophones

Posté par  (site web personnel) . Modéré par Lucas Bonnet. Licence CC By‑SA.
Étiquettes :
33
11
mar.
2011
Python

À l'occasion de la sortie de Python 3.2, deux développeurs français du langage Python, Antoine Pitrou et Victor Stinner (haypo) ont accepté de répondre à quelques questions sur Python.

Et comme ils fréquentent LinuxFr, ils savent quel est le niveau ici (très élevé, tant sur le plan technique que trollifique) ; donc, lâchez-vous dans les commentaires !

Aller plus loin

  • # Où ?

    Posté par  (site web personnel, Mastodon) . Évalué à 7.

    Je n'ai pas trouvé cet entretien, oubli dans la dépêche ?

    WeeChat, the extensible chat client

    • [^] # Re: Où ?

      Posté par  . Évalué à 6.

      C'est une proposition d'entretien, non? à nous de poser les questions. Du coup avec Haypo dans les parages, et vu qu'on est vendredi, ça promet.
      Je n'ai malheureusement pas de questions. Ou alors ce serait trop indiscret.

      "La liberté est à l'homme ce que les ailes sont à l'oiseau" Jean-Pierre Rosnay

  • # Python 3

    Posté par  (site web personnel) . Évalué à 7.

    Il manque quoi pour une adoption massive de Python3 dans les distributions Linux ?

    Commentaire sous licence LPRAB - http://sam.zoy.org/lprab/

    • [^] # Re: Python 3

      Posté par  . Évalué à 1.

      On attend la percée de gentoo.

    • [^] # Re: Python 3

      Posté par  (site web personnel) . Évalué à 4.

      Il manque sans doute le support de bibliothèques hors bibliothèques standard.

    • [^] # Re: Python 3

      Posté par  . Évalué à 3.

      Je ne connais pas python, mais j'ai déjà envisagé d'apprendre, pour scripter des logiciels. Évidemment, si c'est pour investir du temps dans un truc, je préfèrerais apprendre la version la plus récente. Mais voilà, les logiciels que je voudrais pouvoir scripter implémentent seulement python 2.6. Tant que la masse des logiciels n'aura pas changé, pourquoi faire du python 3 tout seul dans mon coin ? (Même chose avec perl 6.)

      • [^] # Re: Python 3

        Posté par  . Évalué à -1.

        python3 est la version par défaut sous archlinux <3

      • [^] # Re: Python 3

        Posté par  . Évalué à 5.

        Même s'il existe des différences certaines entre 2.6 et 3, ce n'est pas non plus un nouveau langage donc de toute façon l'apprentissage ne sera pas perdu. Pars sur ce que tu as besoin dans l'immédiat.

        Sinon une question à nos amis dév: Que pensent-ils de la sortie des Python Tools for Visual Studio par Microsoft ? (http://pytools.codeplex.com/)

    • [^] # Re: Python 3

      Posté par  (site web personnel) . Évalué à 3.

      Une distribution dont je tairais le nom avait pris la décision de faire de Python 3 sont /usr/bin/python, causant d'évidents problèmes de compatibilité. Que pensez-vous de ce choix ?

    • [^] # Re: Python 3

      Posté par  . Évalué à 1.

      C'est deja le cas... enfin, sauf pour ceux qui utilisent des distro à base de vieilleries ( debian par exemple )

  • # Q

    Posté par  (site web personnel) . Évalué à 7.

    Quel est selon vous le point faible de python, le domaine sur lequel il est le plus en retard / handicapé ? (genre multithreading, performances, indentation etc)

    Quels sont les gros projets écrits 100% en python les plus emblematiques ?

    • [^] # Re: Q

      Posté par  . Évalué à 1.

      twisted, django, Zope (certaines partie sont écrite en C)

    • [^] # Re: Q

      Posté par  (site web personnel) . Évalué à 3.

      bazaar, launchpad, mercurial (un peu de C)

      • [^] # Re: Q

        Posté par  . Évalué à 4. Dernière modification le 12 mars 2011 à 09:04.

        bazaar, launchpad

        le monsieur, il a dit emblématique, pas comique ! (git/mercurial, github/bitbucket r0x0r \o/)

    • [^] # Re: Q

      Posté par  . Évalué à 6.

      Shinken ! (bon c'est ptet plus petit mais je sais que l'auteur passe sur linuxfr et que j'ai beaucoup de sympathie pour ce projet :p )

      • [^] # Re: Q

        Posté par  (site web personnel) . Évalué à 3.

        Oh merci ça fait toujours plaisir de lire ce genre de post :)

        Bon sûr ce je retourne coder un module de découverte (réseaux+systèmes) pour Shinken d'ailleurs ;)

    • [^] # Re: Q

      Posté par  . Évalué à 4.

      Pas dans le genre emblématique mais que j'utilise, il y a :

      • scon
      • meld
      • wicd

      Le truc c'est qu'un logiciel python on le reconnais toujours parce qu'il sort pleins de messages d'alerte dans le terminal....

      Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

  • # print "%s %s" % ("hello", "world")

    Posté par  (site web personnel) . Évalué à 5.

    J'ai pas trop suivi l'actualité pythonesque récente, vous êtes-vous enfin décider à laisser l'opérateur % tranquille ou bien êtes-vous toujours déterminés à le faire disparaître au profit de la fonction format() ?

    Les deux devraient pouvoir cohabiter !

  • # Performances de Python

    Posté par  . Évalué à 10.

    Bonjour,

    J'ai 3 questions en tête :

    1. On voit beaucoup en ce moment de nouvelles concernant l'amélioration fulgurante des performances de Javascript (SpiderMonkey dans Firefox, V8 dans Chrom[e|ium]), à base d'optimisations diverses et variées. Pourtant, Javascript n'est pas un langage à priori conçu pour être hyper performant, et ces optimisations sont pourtant réalisables et réalisées.

      En ce qui concerne Python, j'aurai voulu savoir si les performances de l'interpréteur étaient actuellement jugées "bonnes" ou "mauvaises", si des travaux d'optimisation étaient envisageables, envisagées, ou si certaines particularités de la syntaxe empêchaient une optimisation massive de l'interpréteur.

    2. Est-ce qu'on pourrait avoir un état des lieux des systèmes de gestion de paquets disponibles sur Python, avec les outils associés ? J'ai toujours eu un peu cette impression que c'était "le bordel"... Est-ce toujours le cas, par exemple ? Par là, j'entend : est-ce qu'une utilisation non triviale d'un outil personnalisable est envisageable au jour le jour ?

    3. En ce qui concerne l'écriture d'un nouveau projet, indépendamment des bugs et performances de l'interpréteur en lui même, est-il raisonnable de partir sur Python V3 ? Je pense notamment à l'écosystème gravitant autour de Python, et à cette page qui met en exergue le fait que certains paquets importants n'ont toujours pas évolué vers Python V3.

  • # Compilation ?

    Posté par  (site web personnel) . Évalué à 5.

    Je me suis mis il y a quelques temps à Python, je m'en sers au boulot pour des scripts système et j'adore.
    Je fais aussi un peu de développement d'applications dans mon coin pour des besoins persos, avec GTK+ et là aussi, c'est assez génial d'arriver à un résultat concret de façon très rapide et avec peu de lignes de code. C'est vraiment très appréciable.

    Cependant je me pose une question : j'ai bien compris que Python est un langage interprété, et en ce qui concerne les scripts systèmes par exemple il pourrait difficilement en être autrement. Cela dit, au détour de quelques discussions ici et là sur internet, l'argument des détracteurs qui revient assez régulièrement concerne les performances (en ce qui me concerne je n'ai pas eu à en souffrir pour le moment) face au C/C++ qui est bien sûr compilé.

    Du coup, je me demande, ne serait-il pas possible de concevoir un compilateur Python (tout en gardant l'interpréteur bien entendu) ? L'entreprise serait certes assez colossale, d'autant que cela nécessiterait de compiler également l'ensemble des modules tiers, mais après tout, pourquoi pas ? Qu'est-ce qui, techniquement, empêcherait une telle chose ? N'aurait-on pas alors un langage encore plus polyvalent, et du coup susceptible de convenir à un nombre encore plus important de développeurs ?

    There is no spoon...

    • [^] # Re: Compilation ?

      Posté par  (site web personnel) . Évalué à 9.

      Ça me paraît être une bonne idée ça.

      Pour rester compatible avec les bibliothèques existantes on utiliserait libpython pour gérer les objets python, et pour tout les types simples, on rajouterai des instructions pour « définir » le type C correspondant, par exemple au lieu de

      def f(x):
    return x**2-x

def integrate_f(a, b, N):
    s = 0
    dx = (b-a)/N
    for i in range(N):
        s += f(a+i*dx)
    return s * dx

      on aurait

      def f(double x):
    return x**2-x

def integrate_f(double a, double b, int N):
    cdef int i
    cdef double s, dx
    s = 0
    dx = (b-a)/N
    for i in range(N):
        s += f(a+i*dx)
    return s * dx

      Voire même mieux, on stockerait ces définitions dans des fichiers externes pour ne pas avoir à toucher au code python existant.

      Et je suis sur qu'on aurait des performances exceptionnelles ( 30x plus rapide en moyenne ? )

      e qui s'appelorio cython

      http://cython.org/

      • [^] # Re: Compilation ?

        Posté par  (site web personnel) . Évalué à 0.

        Ah ça a l'air super intéressant ça. Tu peux m'en dire un peu plus, je suis pas sûr d'avoir tout pigé ?
        C'est permet de compiler certaines parties de code en python en passant par du C ?

        There is no spoon...

      • [^] # Re: Compilation ?

        Posté par  . Évalué à -1.

        Tiens le duck typing c'est plus la solution à tout les problèmes de la Terre ?

        Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

        • [^] # Re: Compilation ?

          Posté par  (site web personnel) . Évalué à 1.

          Tant que ce n'est pas du lame duck typing…

          Votez les 30 juin et 7 juillet, en connaissance de cause. http://www.pointal.net/VotesDeputesRN

  • # trollesque

    Posté par  (site web personnel) . Évalué à 0.

    Pourquoi python est il vraiment supérieur aux autres langages ?

    PS : ce n'est pas malin de poster ça un vendredi ;-)

    • [^] # Re: trollesque

      Posté par  (site web personnel) . Évalué à 9.

      Parce qu’il est le langage caché des Monty Python et permet une façon très british de coder de façon absurde tout en ayant un code qui non seulement fonctionne, mais aussi fait marrer les programmeurs qui ont à le relire. Il n'y a qu’à se plonger dans les sources des modules lifeofbrian, holygrail ou encore meaningoflife pour s’en rendre compte. On combine ainsi des programmes efficaces et des programmeurs heureux, c’est la raison principale qui fait que Python est supérieur aux autres langages.

      CQFD

      et comme le disait l'autre, import this !

      Votez les 30 juin et 7 juillet, en connaissance de cause. http://www.pointal.net/VotesDeputesRN

    • [^] # Re: trollesque

      Posté par  (site web personnel) . Évalué à 2.

      Je voulais apprendre le python. J'en avais trouvé un mais il ne parlait pas : http://pjarillon.free.fr/pierre/python.jpg , pourtant il était gentil.
      Peut-être que je m'y suis mal pris ?

      • [^] # Re: trollesque

        Posté par  (site web personnel) . Évalué à 2.

        Tu confonds avec le fouchelang.

        • [^] # Re: trollesque

          Posté par  . Évalué à 2.

          s/fouchelang/fourchelang/g

          Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

          • [^] # Re: trollesque

            Posté par  . Évalué à 2.

            On dirait que sa fourche a langué

            Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur

  • # GILi, GILi, GILi, ...

    Posté par  . Évalué à 10.

    Le GIL, quand est-ce qu'on l'enterre ?

    Le multi-threading potable au lieu des Usines à Gaz à la Twisted, c'est pour demain ?

    Tarek Ziadé, il est francais aussi. Il sent le gaz ?

    A quand un vrai toolkit graphique pythonique au lieu des wrappers tout moisis (TK, Qt, GTK, FOX, SWT, ...) ?

    PyPy à la place de CPython en standard, utopie ?

    Distutil 2, un anneau pour les gouverner tous ?

    Question subsidiaire du vendredi: Pourquoi DLFP n'est pas réécrit en Django, si c'était mieux que RoR? (Bref, c'est quoi LE framework Web pour Python qui va disrupter l'innovation à mémére ?)

    • [^] # Re: GILi, GILi, GILi, ...

      Posté par  (site web personnel) . Évalué à 3.

      Question subsidiaire du vendredi: ... DIY c'est sui qui fait qui choice

      Votez les 30 juin et 7 juillet, en connaissance de cause. http://www.pointal.net/VotesDeputesRN

      • [^] # Re: GILi, GILi, GILi, ...

        Posté par  . Évalué à 2.

        DIY c'est sui qui fait qui choice

        C'est un framework développé avec "La Rache-NG", la dernière approche agile plébiscitée par le Gartner, c'est ça ?

        Connais pas !

    • [^] # Re: GILi, GILi, GILi, ...

      Posté par  (site web personnel, Mastodon) . Évalué à 2.

      Tarek Ziadé, il est francais aussi. Il sent le gaz ?

      J'ai ouïe dire que Tarek est très occupé chez Mozilla (à faire du Python bien sûr) :-)

      <mavie>Il m'a d'ailleurs bien longuement convaincu de passer à Python, mais j'ai toujours pas eu le temps de m'y mettre sérieusement..</mavie>

      • [^] # Re: GILi, GILi, GILi, ...

        Posté par  . Évalué à 5.

        Il y a fort longtemps, il m'avait semblé qu'il était question d'embarquer dans XULRunner et dans FF un interprète python.
        Qu'en est-il aujourd'hui ?

        • [^] # Re: GILi, GILi, GILi, ...

          Posté par  (site web personnel, Mastodon) . Évalué à 2.

          Ça fait très longtemps que ça existe. Il est possible en effet de faire des composants XPCOM en python (mais pas de remplacer JS par Python dans les pages XUL ou HTML). Mais ce n'est pas compilé par défaut. Il faut donc se compiler un XulRunner.

          L'éditeur Komodo utilise cette fonctionnalité. Bon nombre de leurs composants sont en python. D'ailleurs, c'est eux qui ont fait le binding XPCOM pour python :-)

    • [^] # Re: GILi, GILi, GILi, ...

      Posté par  . Évalué à 5.

      Le multi-threading potable au lieu des Usines à Gaz à la Twisted, c'est pour demain ?

      Twisted est loin d'être une usine à gaz, de plus, le modèle événementiel asynchrone a le vent en poupe pour tout ce qui est entrées/sorties (les serveurs web haute-performance utilisent quasiment tous ce mode de fonctionnement)

      PyPy à la place de CPython en standard, utopie ? La dernière fois que j'ai tenté de le compiler, ça a réussi à rendre inutilisable une machine quad-core avec 8Go de RAM pendant au moins 5 à 7h.

      Question subsidiaire du vendredi: Pourquoi DLFP n'est pas réécrit en Django, si c'était mieux que RoR? Parce que Django sapusaipaWSGIApproved ;)

    • [^] # Re: GILi, GILi, GILi, ...

      Posté par  . Évalué à 2.

      PyPy à la place de CPython en standard, utopie ?

      Il existe probablement autant d'interpréteur python que de jour de la semaine, quel est celui que vous avez choisi et pourquoi ?

      Pourquoi DLFP n'est pas réécrit en Django, si c'était mieux que RoR? (Bref, c'est quoi LE framework Web pour Python qui va disrupter l'innovation à mémére ?)

      En framework python j'y connais que dalle (moi je suis un vrai j'utilise JSF (JEE power ! ^)), mais bien qu'on cause beaucoup de Django il me semble qu'il a de sérieux concurrents notamment Zope et Pylon (se dernier m'a l'aire intéressant et très flexible).

      Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

  • # Python packaging

    Posté par  . Évalué à 3.

    La dernière fois que j'avais regardé, la situation était un peu complexe. Il me semblait que Tarek Ziadé (un autre dév. français) travaillait là dessus (http://guide.python-distribute.org/).
    Est-ce que la situation c'est éclaircie ?

    Merci.

  • # Nommage dans python

    Posté par  (Mastodon) . Évalué à 7.

    Ne faisant pas de python, chaque fois que je regarde du code python, j'ai l'impression que personne n'utilise les mêmes conventions de nommage et que même à l'intérieur de la lib standard, il y a plusieurs conventions. N'est-ce pas un handicap à son adoption, surtout quand on voit Ruby ou Java qui ont des conventions fortes et respectées à peu près partout ?

  • # Python, la concurrence, et le web

    Posté par  . Évalué à 8.

    Maintenant que CPython 3.2 intégre les travaux d'Antoine sur le GIL (après plus d'un an de travail, chapeau !), quels sont les pistes pour améliorer les performances de Python dans un contexte multicore ?
    Si j'ai bien compris, on a désormais un GIL qui gère les changements de contexte de façon plus équitable et déterministe (basé sur des ticks et non plus sur l'exécution d'opcodes), mais pour autant ça ne résoud pas tout les problèmes du GIL.

    Au niveau de la librairie standard, Python 3.2 arrive avec les futures qui semblent faire consensus (adopté par les langages mainstreams comme Java, C++0x, C#, etc ...) et un nouveau namespace concurrent qui ouvre la porte à pas mal d'améliorations: conteneurs concurrent-friendly, threading haut-niveau (des compréhensions de listes de haut niveau, etc ...), etc ... De ce côté-là, la roadmap semble plus claire, mais concrètement, qu'est-ce qui arrive dans le tuyau ?

    Python, appuyé de frameworks web de qualité (Pylons, TG, Django etc ...) connait un grand succès en tant que langage web. Le passage de WSGI à Python 3 semble trainer depuis quelques temps notamment à cause du choix du type de données pour les flux (unicode ou bytes, ou selon le contexte), où en est-on ? Est-ce que la librairie standard verra un jour son support de WSGI enrichi et qu'on puisse enfin se débarasser de modules à moitié maintenus (mais que tout le monde utilise) comme Flup ?

  • # Et hop !

    Posté par  (site web personnel) . Évalué à 10.

    1. Qu'est ce que vous faites comme travail ? Est-ce que ça implique du Python ? Est-ce que vous êtes payés pour travailler sur le développement de Python ?

    2. Comment êtes-vous arrivés à devenir développeur Python ? Depuis combien de temps ?

    3. Certains projets comme KDE donnent un accès svn facilement (au second patch soumis). D'autres comme gcc ou CentOs n'ouvrent le repository qu'après plusieurs années de travail et sous recommendation. Comment se situe Python de ce point de vue là ? Est-ce difficile de passer de contributeur à développeur, d'obtenir un accès svn (hg maintenant) ? Est-ce que vous pensez que le curseur est au bon niveau ?

    4. La popularité de Python a vraiment augmenté ces dernières années, est-ce que vous en avez vu les conséquences au niveau du développement du langage : plus de bugs reportés ? plus de patchs ? plus de contributeurs ? plus de questions débiles ?

    5. Est-ce que le langage Python a encore besoin d'évoluer ? Le langage est aujourd'hui très complet, est-ce qu'il y a vraiment besoin de lui rajouter des nouveaux trucs ? Le moratorium sur l'immobilité du langage a été levé, est-ce une bonne chose selon vous ?

    6. Qu'est ce que vous pensez de Perl 6 ? Est-ce que vous l'avez regardé ? Est-ce qu'il y a des idées qui pourraient être utilisées dans Python aussi ?

    7. Qu'est ce que vous pensez de la qualité du code actuel de Python ? Pour le passage à Python 3, vous avez pu changer quelques trucs mais aucun changement majeur interne n'était prévu. Est-ce qu'il y a des zones de code où vous vous dite "il faudrait carrément tout réécrire ce truc mais c'est pas possible du tout" ?

    8. Que pensez-vous des efforts pour avoir des interpréteur Python JIT ? Vous y croyez pour le futur de Python ?

    9. Unladen Swallow devait rentrer dans Python, sauf que le projet est l'arrêt. Vous pensez qu'il a encore une chance de rentrer, maintenant que PyPy l'a rattrappé en terme de performance ?

    10. Est-ce qu'il y a des choses qui manquent réellement à Python, ou qui demandent une grosse amélioration, dans l'écosystème Python en général ?

    11. Le passage à Python 3 se fait de façon très lente, beaucoup de projets ne sont toujours pas portés. Est-ce un problème ? Est-ce que Python 3 apporte de réelles solutions ?

    12. En lisant python-dev, j'ai pu apprécier le travail de Victor sur la gestion de l'unicode sur tout ce qui touche à la gestion de fichiers. Si j'ai bien suivi, il reste des cas irrésolvables où on ne pourra pas afficher correctement le nom d'un fichier, voire où on ne pourra pas lire un fichier au nom étrange ?

    13. Certains se plaignent qu'à côté d'un langage comme Lua, Python a un runtime assez gros qui le rend difficile à embarquer sur des petits matériels. Un autre problème est aussi qu'il est impossible d'embarquer plusieurs runtime simultanément. Vous en pensez-quoi ?

    • [^] # Re: Et hop !

      Posté par  . Évalué à -7.

      1. Qu'est ce que vous faites comme travail ? Est-ce que ça implique du Python ? Est-ce que vous êtes payés pour travailler sur le développement de Python ?

      2. Comment êtes-vous arrivés à devenir développeur Python ? Depuis combien de temps ?

      3. Certains projets comme KDE donnent un accès svn facilement (au second patch soumis). D'autres comme gcc ou CentOs n'ouvrent le repository qu'après plusieurs années de travail et sous recommeandation. Comment se situe Python de ce point de vue là ? Est-ce difficile de passer de contributeur à développeur, d'obtenir un accès svn (hg maintenant) ? Est-ce que vous pensez que le curseur est au bon niveau ?

      4. La popularité de Python a vraiment augmenté ces dernières années, est-ce que vous en avez vu les conséquences au niveau du développement du langage : plus de bugs reportés ? plus de patchs ? plus de contributeurs ? plus de questions débiles ?

      5. Est-ce que le langage Python a encore besoin d'évoluer ? Le langage est aujourd'hui très complet, est-ce qu'il y a vraiment besoin de lui rajouter des nouveaux trucs ? Le moratorium sur l'immobilité du langage a été levé, est-ce une bonne chose selon vous ?

      6. Qu'est ce que vous pensez de Perl 6 ? Est-ce que vous l'avez regardé ? Est-ce qu'il y a des idées qui pourraient être utilisées dans Python aussi ?

      7. Qu'est ce que vous pensez de la qualité du code actuel de Python ? Pour le passage à Python 3, vous avez pu changer quelques trucs mais aucun changement majeur interne n'était prévu. Est-ce qu'il y a des zones de code où vous vous dites: "iIl faudrait carrément tout réécrire ce truc mais c'est pas possible du tout" ?

      8. Que pensez-vous des efforts pour avoir des interpréteur Python JIT ? Vous y croyez pour le futur de Python ?

      9. Unladen Swallow devait rentrer dans Python, sauf que le projet est l'arrêt. Vous pensez qu'il a encore une chance de rentrer, maintenant que PyPy l'a rattrappé en terme de performance ?

      10. Est-ce qu'il y a des choses qui manquent réellement à Python, ou qui demandent une grosse amélioration, dans l'écosystème Python en général ?

      11. Le passage à Python 3 se fait de façon très lente, beaucoup de projets ne sont toujours pas portés. Est-ce un problème ? Est-ce que Python 3 apporte de réelles solutions ?

      12. En lisant python-dev, j'ai pu apprécier le travail de Victor sur la gestion de l'unicode sur tout ce qui touche à la gestion de fichiers. Si j'ai bien suivi, il reste des cas irrésolvables insolubles où on ne pourra pas afficher correctement le nom d'un fichier, voire où on ne pourra pas lire un fichier au nom étrange ?

      13. Certains se plaignent qu'à côté d'un langage comme Lua, Python a un runtime assez gros qui le rend difficile à embarquer sur des petits matériels. Un autre problème est aussi qu'il est impossible d'embarquer plusieurs runtime simultanément. Vous en pensez-quoi ?

      • [^] # Re: Et hop !

        Posté par  . Évalué à -2.

        Eh ben, on me reprendra à vouloir filer un coup de main pour préparer le travail, moi !

    • [^] # Re: Et hop !

      Posté par  . Évalué à 1. Dernière modification le 14 mars 2011 à 00:17.

      1) J'ai été payé deux ans pour faire du développement python, surtout développer des interfaces et outils pour un code C++

      2) J'ai découvert Python le jour ou j'ai voulu corriger un bug dans un script pour Blender. J'ai cherché de la doc, je suis tombé sur le texte de Gérard Swinnen. J'ai commencé à tester les exemples, changer deux trois trucs, chercher un peu plus loin ... en quelques jours j'avais adopté Python. C'était il y a à peu près 7 ans.

      4) Je ne peux pas vraiment répondre à tes questions mais où je vois un gros changement c'est dans le nombre d'applications scriptables en Python. Il y a quelques années, toutes les applis (surtout scientifiques) avaient leur propre langage de script. Maintenant on en voit de plus en plus proposer Python par défaut ou comme deuxième langage de script.

      5) Vaste question. Tout ce que je peux dire c'est que je suis bien content des modifs apportées par Python 3. Ça corrige plein de petits truc chiant des 2.x. Le passage à tout unicode est pour moi le gros plus de la version 3. Pour les améliorations, je dirai corriger encore pas mal de bugs dans la bibliothèque standard, fournir un type orienté objet pour la gestion des chemins, pourquoi pas intégrer par défaut une bibliothèque simple pour écrire des extensions en C/C++ (style boost.Python ou SWIG)

      7) Je n'ai pas fait la migration vers Python 3 car les bibliothèques que j'utilisais n'étaient pas portées et Python 3 n'était pas installé/dispo sur les machines des utilisateurs. J'ai juste préparé le code pour une future migration. J'ai du récrire toute la partie chaine de caractère/unicode justement mais c'était une bonne chose, ça a grandement amélioré la qualité du code. Sinon, non, rien ne semblait insurmontable.

      10) Clarifier le système de distribution de paquets, je trouve aussi que c'est un peu bordélique.

      11) C'est un peu un problème (voir point 7.). Python 3 apporte plein de bonnes choses mais qui ne parlent pas du tout à beaucoup d'utilisateurs de Python. Dans ce que j'ai vu (domaine des sciences physiques), beaucoup l'utilisent comme langage de script de manière très basique (pas de fonctions, pas de classes, pas de gestion des encodages car tous ont pris l'habitude de tout écrire sans accents, etc) car ce n'est pas leur priorité et sont donc plus proche d'une syntaxe 1.x que 3. Pour eux les changements apportés par Py3 ne sont donc que des emmerdements.

      12) Ahh, j'ai raté ça. Je vais regarder ça de plus près ! J'avais trouvé des bugs très chiants (déjà signalés je crois) sur des fonctions de base de os.path. Par exemple 

      os.path.relpath(u'test') #-> u'test' renvoie unicode (normal)
os.path.relpath(u'.') #-> '.' renvoie str ?!?

      Pour les 3,6,8,9,13 je n'ai pas suffisamment (ou pas du tout) de connaissance dans ces domaines pour répondre

      • [^] # Re: Et hop !

        Posté par  (Mastodon) . Évalué à 2.

        '7. C'est un peu un problème (voir point 7.)'

        Stack overflow

        • [^] # Re: Et hop !

          Posté par  (site web personnel) . Évalué à 2.

          en mettant des parenthèses, ça évite de se faire rattraper par la numérotation automatique du Markdown :-)

  • # Perl

    Posté par  . Évalué à 2.

    • On a tendance à voir Perl et Python comme deux frères « ennemis » empruntant chacun une voie diamétralement opposée, qu'en pensez-vous ?
    • Y as-t'il des communication entre les deux projets ou une inspiration de l'un à l'autre ? (même s'il est claire que l'énorme majorité des fonctionnalités de l'un ne peuvent aller dans l'autre et vice versa)

    Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

    • [^] # Re: Perl

      Posté par  (site web personnel) . Évalué à 2.

      Les perleux et les pythoneux disent à chaque conférence que « la version x a tout cassé, c'est un changement énorme, encore plus que dans [insérez le langage ennemi], donc on reste sur la version x-1 en attendant que toutes les librairies soient enfin portées.» Quand tu vois une conférence Perl suivie ensuite d'une conférence Python, tu trouves beaucoup de similitude dans les discours.

      Commentaire sous licence LPRAB - http://sam.zoy.org/lprab/

  • # Python et Mono

    Posté par  (site web personnel) . Évalué à 1.

    Sous systèmes GNU/Linux, Python est pas mal utilisé. Est-il un concurrent de Mono qui a aussi du succès (un peu moins, certes...) ? Quels sont les avantages/inconvénients de chacun ?

    Mono permettrait un portage facilité vers Windows (.Net) et vice-versa, Python permet-il aussi facilement (ou mieux) de réaliser des applications multi-plateforme (Linux, Win... mais aussi Mac et peut-être dans l'embarqué ?) ?

    Les développeurs Python travaillent ils majoritairement sous OS libre ? Si oui, est-ce dû au fait que le code est nécessairement ouvert avec Python ?

    Mono me fait peur en raison des brevets susceptibles de s'appliquer dans les pays reconnaissant les brevets logiciels : Python présente t-il le même genre de risques (je ne demande pas si Python est 100% patent-proof, je sais que c'est quasi-impossible à affirmer compte tenu des dérives actuelles en matière de brevets, mais je me demande si les brevets susceptibles de s'appliquer de la façon la plus évidente à Mono ou Java pourraient concerner Python (par exemple le mécanisme consistant à interpréter le code à la volée est-il breveté par Sun/Oracle ou MS ou bien y a t-il un "prior art" ou autre chose (mécanismes différents...) permettant d'écarter ce risque ?) Je ne suis pas développeur, peut être la question est elle débile...

    • [^] # Re: Python et Mono

      Posté par  . Évalué à 1.

      Je pense que le vrai concurrent de Mono c'est Vala.

      Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

      • [^] # Re: Python et Mono

        Posté par  . Évalué à 3.

        Faisant du Vala a mes heures perdues... certainement pas.

        Vala est très orienté GLib/GObject/Gtk. Le complilateur souffre de problèmes encore graves, qui font qu'un code qui compile avec la version X, ne compilera pas avec la version Y (X < Y). Bref, vala est encore expérimental, et très orienté Linux pour le moment.

        Le concurrent de C#, c'est plutôt Java qui ont tout les 2 un compilateur en Code Objet et un interpretteur JIT. Python a plutôt comme concurrent, Perl et Ruby d'après ce que je vois.

        • [^] # Re: Python et Mono

          Posté par  . Évalué à 2.

          Ça dépend de ce qu'on entends par concurrent. Parce que dans les faits, .Net n'a pas d'alternative (ou que ce soit, libre ou non). Java commence à peine à supporter d'autres langages (Scala, Groovy), mais ce n'est rien comparé à ce que fait .Net avec C# et les langages supportés par la plateforme.

          Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

    • [^] # Re: Python et Mono

      Posté par  . Évalué à 2.

      Tout logiciel un peu compliqué (comme Python) va enfreindre plusieurs brevets aux USA. Je serais donc très étonné si ce n’était pas aussi le cas de Python (machine virtuelle, garbage collector, j'en passe et des meilleures).

      Concernant la comparaison avec Mono, il y a eu un article dans GLMF expliquant que Mono était plus risqué que les implémentations libres de Java. Je ne sais plus pourquoi, cependant, il est raisonnable de penser que Python lui même est moins risque qu'une implémentation libre de Java car il n'essaie pas de suivre une plateforme abondamment brevetée. D'ailleurs l'article de GLMF s'est un peu planté: Google s'est fait attaquer par Oracle pour Dalvik, alors que Mono ne s'est pas fait attaqué. Il est vrai que MS n'a aucun intérêt a tuer Mono, a l'inverse d'Oracle avec Dalvik.

      Maintenant en ce qui concerne la probabilité d'une attaque sur Python, elles sont quasi nulles a mon avis. Qui pourrait se faire du blé en attaquant Python directement? Personne, donc zéro intérêt.

  • # Questions sur CPython et les autres implémentations

    Posté par  . Évalué à 2.

    • Est-ce que CPython est toujours le maître incontesté des interpréteurs Python?
    • Où en sont les implémentations alternatives à CPython?
    • Est ce que le moratorium sur l'immobilité du langage a porté ses fruits? i.e. est ce que les implémentations alternatives à CPython ont pu rattraper leur retard?

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.