Un nouveau newsgroup en francais sur Python

Posté par  . Modéré par Fabien Penso.
Étiquettes : aucune
0
15
mai
2001
Python
La hierarchie des fr.comp.lang vient de s'enrichir d'un nouveau groupe consacré à Python.
[au fait, le logo Python est plus trop adapté, puisque BeOpen et Python ont plus ou moins "divorcés" suite à la disparition de BeOpen!]
Note du modérateur: si vous en avez un autre mieux que celui là ...

Aller plus loin

  • # Quel domaine d'application ?

    Posté par  . Évalué à 0.

    Sans vouloir troller, à quoi sert ce langage ? Plus précisemment, quels sont les domaines d'applications types où il est plus efficace/plus adapté/... qu'un autre ?

    Merci
    • [^] # Re: Quel domaine d'application ?

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

      Python est assez général.
      On peut s'en servir pour
      - écrire des petits scripts
      - installer des distrib (l'install de la RedHat est en Python paraît-il)
      - faire des cgi
      - écrire des applications (cf wxPython, mais aussi PyGtk, PyKDE et l'interface avec Tcl/Tk)
      - plein d'autres choses...

      Ces forces (attention, avis subjectif :o) sont la clarté de sa syntaxe et la qualité des librairies fournies avec (protocoles Internet, lecture des archives... j'en passe et des meilleurs)

      Un bon exemple d'application concrète écrite en Python : Sketch, un outil de dessin vectoriel. http://sketch.sourceforge.net/(...)
    • [^] # Re: Quel domaine d'application ?

      Posté par  . Évalué à 1.

      Mouai un exemple vraiment interressant est son
      application dans Zope.

      Zope est lui meme une application.

      http://www.zope.org/Members/michel/ZB/ScriptingZope.dtml(...)

      python est un langage extensible, objet et fonctionnel

      Il peut cooperer sans probleme avec perl par exemple et permet un devellopement rapid d applis
      java grace a jython
    • [^] # Re: Quel domaine d'application ?

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

      ça sert à la meme chose que le Perl (en gros) d'ailleurs Perl versus Python est un bon troll à lancer (ça vaut pas mdk/deb ou vi/emacs mais bon)
      Trois questions (sur perl ou python)
      - Est il possible de compiler du python (le perl chie un peu quand j'essaye de compiler un programme un peu complexe avec des modules), python est un excellent language (comme perl) multiplateforme (comme perl et c'est vraiment classe) mais quand on veut distribuer les programmes qu'on a fait sur une autre plateforme que celle qui sont distribué gratuitement avec les interpreteurs integrés, c'est plutot dur, d'ou l'utilité d'un compilateur.
      - (deuxieme question) existe-t-il un "traducteur" python<->perl (pour transformer automatiquement des programmes pythons en perl ou l'inverse) c'est juste par curiosité, les deux languages se positionnent un peu sur le meme creneau et les memes fonctionnalités.
      - troisieme question : existe-t-il un site qui recense les jeux développés en perl (comme pyGames voir liens sur la news)

      Axel - 584
      • [^] # Re: Quel domaine d'application ?

        Posté par  . Évalué à 0.

        java byte code rulezz :)
        • [^] # Jython ou Java et Python

          Posté par  . Évalué à 0.

          bien que quand on pense Python, la plupart du temps c'est C-Python ("l'interpreteur" est ecrit en C (bien que "moteur d'execution" est plus approprie qu'interpreteur)

          il existe aussi Jython, un "moteur d'executiion" ecrit en Java et permettant d'appeler Python de Java et Java de Python

          http://www.jython.org/(...)
      • [^] # Re: Quel domaine d'application ?

        Posté par  . Évalué à 1.

        - Est il possible de compiler du python


        Oui, c'est possible, mais attention, l'exécutable résultant est assez gros... Un utilitaire est fourni dans les sources de Python, dans le répertoire Tools/freeze.


        Mais attention, l'exécutable résultant dépend de la plateforme : s'il a été généré sous Linux, il ne tournera pas sous Windows... Enfin, autnat que je sache.

        • [^] # Re: Quel domaine d'application ?

          Posté par  . Évalué à 1.

          Mais attention, l'exécutable résultant dépend de la plateforme
          Ben oui :o) Normal quand tu compiles en langage machine (ou quelque soit le nom qu'on donne a se langage)
      • [^] # Re: Quel domaine d'application ?

        Posté par  . Évalué à 1.

        on peut créer un exécutable avec "freeze" qui
        contient l'interpréteur, les modules utilisés et
        ton script

        dans la pratique je ne sais pas si ca marche
        vraiment bien dans les cas complexes, ca
        n'intéresse pas beaucoup de monde

        pour une conversion python<->perl, un bon point
        de départ si tu veux le développer est :
        http://starship.python.net/~da/jak/cookbook.html(...)

        Félicitations à celui qui arrive à parser du
        perl. Dans python il y a un module "tokenize",
        et dans perl ?

        Python->Perl est sûrement plus simple (mais
        bizarrement ca n'intéresse personne)
        • [^] # Re: Quel domaine d'application ?

          Posté par  . Évalué à 1.

          Python->Perl est sûrement plus simple (mais
          bizarrement ca n'intéresse personne)

          Mouai tu as raison la dessus ..

          mais en tout cas sous python on peut appeler
          des partis perl
          http://theoryx5.uwinnipeg.ca/CPAN/data/pyperl/README.html(...)
        • [^] # Re: Quel domaine d'application ?

          Posté par  . Évalué à 0.

          on peut créer un exécutable avec "freeze" qui
          contient l'interpréteur, les modules utilisés et
          ton script


          Hum, dans ce cas ça ne réponds pas à sa question qui est de savoir si on peut compiler du pyhton : ce que tu décris ressemble simplement au script empaqueté avec les modules qui vont bien et l'interpréteur pour que le tout marche sur une machine ou python n'est pas installé.

          Pour ce qui est des compilateurs, je connais un projet : http://vyper.sourceforge.net/(...) c'est une extension à python avec un proto-compilateur écrit en OCaml.
          • [^] # Re: Quel domaine d'application ?

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

            Ben si ça répond à mon avis pas mal à la question. Pour moi "compiler" ça veut bien dire faire un exécutable. Et c'est bien ce que fait "freeze". Il transforme le source Python en un exécutable (binaire ELF ou .exe selon l'humeur) que ton OS peut ensuite exécuter. C'est pas étonnant qu'il y ait un équivalent de l'interpréteur contenu dans l'exe, t'as pas trop le choix pour un langage de script...

            Par contre - mais c'est une autre question - Python fait partie de ces langages de script - Perl aussi je crois - où il y a une phase de pré-machage du boulot. A savoir ton source .py est en général transformé en un "bytecode" .pyc qui est ensuite exécuté par l'interpréteur Python. Et on peut raisonnablement espérer que "freeze" effectue automatiqument - au moins - la phase de transformation du source en bytecode.
            • [^] # Re: Quel domaine d'application ?

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

              D'après ce que tu me dit (j'utilise pas python), les fichiers .pyc sont du bytecode. C'est effectivement une phase de compilation mais a l'execution les fichiers bytecode sont lus par une machine virtuelle. C'est plus efficace que du code interprete mais moins que des executables en langage machine que produirait un "vrai" compilateur (du moins dans le sens ou moi je l'entends habituellement).
              • [^] # Re: Quel domaine d'application ?

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

                En fait, c'est vrai qu'un couple interpréteur+bytecode est moins performant que du binaire vraiment optmisé pour tel ou tel proc.

                Ceci dit quand on utilise un langage de script comme Python pour faire une appli, on a le droit - et c'est même recommandé - d'écrire les composants critiques en C. Concrètement sur la plupart des programmes, 5% du code bouffent 95% du CPU, et les 95% de code restant bouffent seulement 5% du CPU. Donc l'idée est d'écrire les composants critiques en C et puis voilou...

                Par exemple si tu veux faire une grosse appli 3D temps réel en Python:
                - tu laisse la carte 3D si elle existe accélerer les parties "pure 3D"
                - tu fais un peu de code C pour les quelques traitements critiques "inclassables"
                - tu bouche les trous avec du Python, qui sert de "liant" à tous les bouts de code critique optimisés.
                Et normalement, en faisant comme ça, tu évites de perdre un temps fou à développer tout en 100% C. Par exemple pour ce qui est de l'interface graphique, c'est beaucoup simple avec Python (et de manière générale avec la plupart des langages de script) qu'avec du C.
    • [^] # Re: Quel domaine d'application ?

      Posté par  . Évalué à 0.

      un bon avocat de python est Eric S.Raymond.
      il l'a utilisé pour fetchmailconf, et explique son choix :
      http://noframes.linuxjournal.com/lj-issues/issue73/3882.html(...)
      depuis, il l'a utilisé aussi pour cml2, le futur système de configuration du kernel linux. initialement prévu pour le kernel 2.5, mais il risque d'arriver bien avant apparemment.

      à part ça c'est un langage très utilisé pour les applications numériques et spécialement en bioinformatique : http://bioinformatics.org(...)
      • [^] # Re: Quel domaine d'application ?

        Posté par  . Évalué à 0.

        à part ça c'est un langage très utilisé pour les applications numériques et spécialement en bioinformatique : http://bioinformatics.org(...)

        Bof, un language de script interprété, c'est un peu rédhibitoire pour la bioinfo où il faut brasser de gros volumes de données, non ?
        • [^] # Re: Quel domaine d'application ?

          Posté par  . Évalué à 0.

          La bioinfo demande, entre autre, de traiter des gros volumes de données.
          En fait python s'en sort pas trop mal notamment parce qu'il donne un accés facile aux bases de données, et aussi parce que tu peux toujours executer un utilitaire appellé freeze, qui permet d'avoir un binaire executable.
          Python apporte d'autres choses :
          - il supporte de manière native les entiers longs et les complexes (c'est à peu près le seul)
          - il supporte les expressions régulières (pas aussi bien que perl)
          - il est facile à lire (n'oublie pas qu'en bio on a pas toujours affaire à des informaticiens)
          • [^] # Re: Quel domaine d'application ?

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

            Il est également assez économe en mémoire, à ce que j'ai vu.

            Par contre, niveau vitesse, ça donne quoi pour des gros tableaux qui remplissent ta mémoire ?
          • [^] # Re: Quel domaine d'application ?

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

            tu peux toujours executer un utilitaire appellé freeze, qui permet d'avoir un binaire executable.
            Je vois pas trop l'intéret a part pour distribuer facilement le programme.

            - il supporte de manière native les entiers longs et les complexes (c'est à peu près le seul)
            Mouais, les complexes en biologie j'ai pas encore vu où ça peut servir ... ;-)

            - il est facile à lire
            Effectivement.


            Ce que je voulais dire, c'est que traiter beaucoup de données, ça prend beaucoup de temps et que pour pas mal d'algorithmes, seul un langage compilé permet d'avoir une implémentation efficace en pratique (alignements de séquence par exemple).
            • [^] # Re: extension en C

              Posté par  . Évalué à 0.

              ben je sais pas comment travaille les bioteurs,
              mais quand ca rame en python pur, tu ecris une extension en C (ou C++) et tu l'appelles de python
      • [^] # Digital Domain utilise Python

        Posté par  . Évalué à 0.

        et Gnumeric utilise Python aussi :)

Suivre le flux des commentaires

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