Articles précédents : Développeur
- [0] 4 Interviews FOSDEM 2007
- [44] OCaml summer project
- [10] 3 jours de Hackfest à Solutions Linux 2007, du 30 Janvier au 1er Février
- [105] Et les femmes ?
- [6] Résultat des troisièmes Trophées du Libre
- [8] Deux concours autour de Qt
- [1] PortailPHP 2.0 est sorti
- [19] Première implémentation du langage Fortress
- [4] Web Component Development with Zope 3
- [104] Le langage D 1.00 est disponible !
Liens connexes
- PyPy (1124 hits)
- Annonce de la version 0.99 (224 hits)
- Rapports de recherche (272 hits)
Dépêche modérée par
Dépêche éditée par
Développeur : PyPy, le serpent qui se mord la queue, sort en version 0.99
Posté par Victor STINNER (page perso, ). Modéré le 22 février 2007.
PyPy apporte de nombreuses améliorations à Python comme les « espaces d'objet », la programmation logique, la programmation concurrente, etc. Une partie de l'interpréteur Python est écrite en RPython, sous-ensemble limité de Python, ce qui permet de le compiler pour LLVM, .NET ou encore en C.
La version 0.99 apporte un backend pour la plateforme .NET, beaucoup de travail sur le backend JavaScript (AJAX fonctionne), et les derniers modules Python qui manquaient ont été écrits : mmap, signal, bz2 et fcntl.
Encore une fois, un gros travail a été fait sur l'optimisation : limitation des appels à malloc(), inlining, accélération des dictionnaires, etc. Cette version est deux fois plus rapide que la précédente, mais l'ajout du compilateur JIT devrait encore améliorer les performances de la prochaine version.
![[en]](../../../images/en.png)
PyPy (1124 hits)-
Annonce de la version 0.99 (224 hits)
-
Rapports de recherche (272 hits)
> Lire la suite (51 commentaires, moyenne: 3). [dépêche : 735 caractères]
- Un compilateur JIT qui devrait encore améliorer les performances. Il n'a pas été intégré à la version 0.99 car il ne donnait pas les résultats escomptés.
- Des extensions au parseur permettant de modifier la grammaire de Python. En particulier, on pourra facilement ajouter à Python des notions de programmation orientée aspect et de programmation par contrat.
- L'espace d'objet logique qui offre des variables logiques (à la manière de Prolog) et un résolveur de contrainte.
Ce n'est pas un effet d'annonce, le code existe et fonctionne, mais soit le code n'est pas assez testé, soit il est encore mal intégré au projet PyPy.
un très bon exemple
pour ceux que ça interesse, il y a une petite manip décrite ici qui permet d'effleurer les possibilités de pypy :
http://programming.reddit.com/info/152lr/comments/c156v0
Moi ce projet, il me fait délirer. Et le gain qu'il va apporter à python est incommensurable ...
-
[^]Re: un très bon exemple
Posté par ploum (page perso, ) le 22/02/2007 à 09:45. (lien). Évalué à 6.Tu peux m'expliquer et me donner des exemples de ce que ça va apporter ? Personnellement, je trouve ça chouette comme recherche théorique, mais je ne vois pas d'intérêt direct en fait. (j'ai pas approfondi non plus)
-
[^]Re: un très bon exemple
Posté par ccomb (Jabber id, page perso, ) le 22/02/2007 à 09:50. (lien). Évalué à 5.J'étais justement en train de poster un commentaire similaire.
Les choses sont expliquées ici, mais je n'ai jamais lu de vulgarisation bien faite.
http://codespeak.net/pypy/dist/pypy/doc/architecture.html#mi(...)
On entend juste « implémentation de python en python ». Après une introduction comme ça, 1% des gens vont prendre la peine de creuser un peu pour découvrir ce que ça apporte.
-
[^]Re: un très bon exemple
Posté par manatlan (Jabber id, page perso, ) le 22/02/2007 à 09:58. (lien). Évalué à 6.oui, j'ai aussi beaucoup de mal à cerner la bête ... même après la lecture (ultra interessante) du site de pypy ...
Le premier gros apport, c'est facilité la maintenance/evolution de python. Python est codé en C, et l'ajout de fonctionnalités/evolutions commence à devenir un petit cauchemar dans certains cas. Le fait de pour coder python, en python va énormément simplifier la maintenance/evolution du language.
Un autre apport, c'est la couche basse "rpython", si j'ai bien compris. Tout en programmant en python, on pourra targetter ... soit du C, soit du .Net, soit du javascript (d'autres devrait suivre, pk il suffit de faire les traductions "rpython -> destination").
Développer une appli web entièrement en python, qui fabriquera le code JS/ajax coté client est déjà une réalitée ( http://play1.codespeak.net:8008/ )
Une fois la VM bien rodé, d'autres languages (ruby par exemple, en fabriquant le traducteur ruby->rpython) pourrait générer du python, du c, du .net ou autres ... bref, le début d'une VM communautaire (ala CLR)
(Et je crois qu'il y a aussi l'idée de réduire le runtime au minimum)
Voilà ce que j'ai un peu prêt compris ...-
[^]Re: un très bon exemple
Posté par Éric Martin () le 22/02/2007 à 10:06. (lien). Évalué à 2.Il y a beaucoup de confusion à propos de pypy, Beaucoup pensent que pypy va permettre de convertir de code python en C, mais ce n'est pas le cas, il ne permet que de convertir du code Rpython en d'autre language et selon les développeur de pypy (en tous cas ceux qui était sur #pypy sur freenode quand je me suis informé), Coder en Rpython est plutôt chiant et celui-ci n'est destiné qu'à coder Python en Rpython et non coder des applications...
-
[^]Re: un très bon exemple
Posté par manatlan (Jabber id, page perso, ) le 22/02/2007 à 10:29. (lien). Évalué à 1.tu devrais relire ici :
http://codespeak.net/pypy/dist/pypy/doc/getting-started.html(...)
il y a des exemples où il transforme clairement un fichier ".py" en binaire executable (via llvm)... tout n'est pas encore au point certes ...
-
-
[^]Re: un très bon exemple
Posté par Victor STINNER (page perso, ) le 22/02/2007 à 10:46. (lien). Évalué à 5.Le premier gros apport, c'est facilité la maintenance/evolution de python. Python est codé en C, et l'ajout de fonctionnalités/evolutions commence à devenir un petit cauchemar dans certains cas.
De par sa nature très modulaire, PyPy permet également des changements majeurs dans l'implémentation de Python. CPython utilise par exemple un ramasse miette à générations. C'est un choix, mais PyPy en permet d'autres, ce qui permet de comparer les performances et de choisir une alternative qui serait plus rapide dans un cas précis. D'ailleurs, PyPy a déjà des outils pour supprimer des malloc().
La mémoire n'était qu'un exemple, mais la gestion des processus concurrents est également remise en question : thread, greenlets, proxy d'objet fonctionnant sur réseau, clonage de générateur... PyPy apporte encore une fois un air frais dans ce domaine.
Et alors que CPython n'optimise peu ou pas, PyPy fait de l'inlining, a un annotateur de type, permet de compiler dans de nombreux langages, etc. Il offre la possibilité d'optimisations très complexes qui seraient impossibles avec CPython.-
[^]Re: un très bon exemple
Posté par Philippe Fremy (page perso, ) le 22/02/2007 à 11:20. (lien). Évalué à 7.Le site web de pypy est out en ce moment, mais dans mon souvenir, le principal intérêt de pypy est d'avoir une espèce de générateur d'interpréteur python.
Au lieu d'avoir un interpreteur python avec des fonctionnalités édictées une fois pour toute dans la spec, on pourrait "faire ses courses" en terme de fonctionnaliteset générer un interpréteur sur mesure.
Cela permet de modifier la grammaire de python pour des projets dédiés (programmation oriente aspect, programmation par contrat sont les exemples cités, mais on peut en trouver d'autres). On garde donc les principes de base du langage python, mais les fonctionnalités sont extensibles à merci.
J'avais posé une question à l'époque sur la faisabilité d'une inférence de type à la ocaml. C'est là qu'on m'a renvoyé vers pypy où ce genre de chose est envisageable (meme si je ne crois pas que ce soit au programme pour l'instant).
En ce qui me concerne, ce qui m'intéresserait à l'heure actuelle, ce serait une réduction de fonctionnalité : dans la façon dont j'utilise python, le typage dynamique me crée plus de problèmes qu'il n'en résoud. Je préfererai avoir un typage statique, ou en tout cas, l'interdiction a une variable de changer de type au cours de son existence. C'est possible grâce à pypy.
Maintenant, les inconvénients : d'une part, c'est quand même beaucoup plus lent, alors que python n'est déjà pas renommé pour sa vitesse. Ensuite, ça veut dire qu'on va peut-être récuperer des softs qui ne marchent qu'avec un certain jeu de fonctionnalité de l'interpréteur python, et qu'ils seront incompatibles avec d'autres softs utilisant un jeu de fonctionnalité différent.
-
-
[^]Re: un très bon exemple
Posté par Sytoka Modon (page perso, ) le 22/02/2007 à 19:43. (lien). Évalué à 5.> bref, le début d'une VM communautaire
Cela existe déjà, cela s'appelle Parrot. C'est une machine orienté pour les langages de script contrairement à la JVM et à .Net.
http://www.parrotcode.org/
-
-
[^]Re: un très bon exemple
Posté par Wawet76 (page perso, ) le 22/02/2007 à 09:58. (lien). Évalué à 10.L'intérêt est évident : Si a force d'optimisation PyPy devient plus rapide que CPython, il suffira de lancer PyPy sous PyPy pour qu'il soit encore plus rapide. Et ainsi de suite, on peux tendre vers un temps d'exécution nul en empilant les PyPy.
C'est méga-prometteur quoi !-
[+] [^]Re: un très bon exemple
Posté par Guillaume Coré (page perso, ) le 22/02/2007 à 11:14. (lien). Évalué à -9.S'il est plus rapide que CPython, il est plus rapide que CPython, point.
Je ne vois pas pourquoi lancer plusieurs fois pypy sur lui même le rendrait plus rapide-
[^]Re: un très bon exemple
Posté par baud123 (Jabber id, page perso, ) le 22/02/2007 à 11:40. (lien). Évalué à 8.humour toussa ;-)
le paradoxe de Zénon à l'envers si tu veux ;-)-
[^]Re: un très bon exemple
Posté par Guillaume Coré (page perso, ) le 23/02/2007 à 03:12. (lien). Évalué à 3.oups désolé :)
(non pas désolé, j'ai eu les moins que je méritais)
-
-
[^]Re: un très bon exemple
Posté par manatlan (Jabber id, page perso, ) le 22/02/2007 à 11:46. (lien). Évalué à 4.je crois que c'était une blague ;-)
même un blague culturel, car la devise de pypy (si je me souviens bien, car le site est down now), c'est "faster than C"-
[^]Re: un très bon exemple
Posté par spart (page perso, ) le 25/02/2007 à 11:02. (lien). Évalué à 0.> la devise de pypy (si je me souviens bien, car le site est down now)
"pypy, faster than CaCa" ?
-->[]
-
-
-
-
Et pour Caml ?
Maintenant que PyPy est sur la bonne voie, est-ce que l'équivalent va être écrit pour Caml ?
Le jour ou l'UE aura financé PyPy et CaCa, on peut dire que la boucle sera alors bouclée.
Uhm, ok ... --> []
-
[^]Re: Et pour Caml ?
Posté par dbaelde (page perso, ) le 22/02/2007 à 10:49. (lien). Évalué à 4.Hihi..
En l'occurence le compilo Caml est bootstrapé depuis le début (dès Caml Light). Le runtime est écrit en C, mais la complexité bytecode Caml n'a rien à voir avec Python et même RPython.
L'avantage principal de cette approche est la maintenabilité -- écrire un compilo en Caml est inifiniment plus agréable qu'en C à mon gout. Accessoirement, ça assure que les gens qui écrivent le compilo programment dans le langage de destination, et s'impliquent donc sur sa qualité...
Pour finir, je suis déçu de lire que RPython est inutilisable. Quand j'ai appris l'existence de RPython je me suis dit que les Pythoneux découvraient enfin les horreurs cachées de leur langage et les écartaient en créant un sous-ensemble propre, RPython. Visiblement ce n'est pas le cas.-
[^]Re: Et pour Caml ?
Posté par ducon anonymous () le 02/03/2007 à 09:27. (lien). Évalué à 1.euh, pourquoi inutilisable ?
RPython reste infiniment plus agréable que du C en tous cas. C'est un langage jeune, car il a moins de deux ans d'âge, alors il faut un peu d'indulgence ... :)
-
-
[^]Re: Et pour Caml ?
Posté par Farvardin (page perso, ) le 22/02/2007 à 11:02. (lien). Évalué à 10.oui, c'est de la Programmation Objet en Programmation Objet (PoPo), on a ainsi PyPy, CaCa et PoPo.
---> (oui je sais, commentaire de chiotte...)--
You can't grep dead trees...-
[+] [^]Re: Et pour Caml ?
Posté par karmatronic () le 22/02/2007 à 12:17. (lien). Évalué à -5.excellent !
je te laisse je vais faire pypy-
[+] [^]Re: Et pour Caml ?
Posté par Thomas Douillard () le 22/02/2007 à 12:27. (lien). Évalué à -1.C'est drôle uniquement si tu es dev de pypy. sinon, commentaire caca.
-
[^]Re: Et pour Caml ?
Posté par chl (page perso, ) le 22/02/2007 à 14:37. (lien). Évalué à 10.Vous faites chier avec vos commentaires de merde. Vous feriez mieux d'aller pisser du code.
-
[+] [^]Re: Et pour Caml ?
Posté par Christophe Roland (page perso, ) le 22/02/2007 à 15:13. (lien). Évalué à -3.pysser du code?
-
-
-
-
[^]Re: Et pour Caml ?
Posté par nayco (page perso, ) le 22/02/2007 à 21:32. (lien). Évalué à 5.Ca, il a fallu que tu en rajoute une couche...
-
-
[^]Re: Et pour Caml ?
Posté par davux (Jabber id, page perso, ) le 23/02/2007 à 00:47. (lien). Évalué à 2.Non, il faudra un papier qui couvre ce qui a été fait.
-
[^]Re: Et pour Caml ?
Posté par Nicolas Dumoulin (Jabber id, page perso, ) le 23/02/2007 à 08:07. (lien). Évalué à 2.Déjà qu'il paraît que le java est durétique :-/
Lent ...
il n'est plus que 3x plus lent que l'implémentation de référence (CPython)
Ca parait quand même enorme comme différence de preformance, même avec l'interpreteur JIT je ne sais pas si ils arriveront a rattraper un tel retard ... cela ne seras t il pas un frein a son adoption ?
-
[^]Re: Lent ...
Posté par manatlan (Jabber id, page perso, ) le 22/02/2007 à 10:16. (lien). Évalué à 4.> si ils arriveront a rattraper un tel retard
Il y a qques temps pypy était 20x plus lent que cpython ...
Mais si tu peut generer du C (et donc du binaire après coup) à partir d'un source python ... comme c'est un peu décrit ici :
http://programming.reddit.com/info/152lr/comments/c156v0
Et obtenir des performances 70 à 100x supérieur à cpython, le jeu en vaut la chandelle.-
[^]Re: Lent ...
Posté par Joc M () le 22/02/2007 à 14:29. (lien). Évalué à 3.Hé mais, dans ce cas, on pourra compiler pypy en C avec lui même et obtenir une VM python en C qu'on compilera pour obtenir un binaire qui rox dans l'exécution des programmes pythons.
C'est fou ce qu'on peut s'embrouiller avec tout ça.--
be a sheep isn't cheap
-
-
[^]Re: Lent ...
Posté par Victor STINNER (page perso, ) le 22/02/2007 à 10:36. (lien). Évalué à 2.CPython ne permet pas de faire de la programmation logique et Stackless Python est moins poussé en programmation concurrente. PyPy apporte également la fonctionnalité de « clonage de générateur », outil très utile dans le calcul distribué. Et on pourrait encore trouver une longue liste de fonctionnalités qu'apporte PyPy.
Le problème des performances va peu à peu s'effacer et je pense qu'à terme PyPy sera plus rapide.
-
[^]Re: Lent ...
Posté par Clément Schreiner (page perso, ) le 22/02/2007 à 15:32. (lien). Évalué à 1.1- il y a environ un an pypy était cent ou deux cents fois plus lent que cpython
2- pypy est pour l'instant lancé avec cpython, donc il est forcément plus lent :)
(corrigez moi si je me trompe, pour le 2- :)-
[^]Re: Lent ...
Posté par Victor STINNER (page perso, ) le 22/02/2007 à 15:59. (lien). Évalué à 3.2- pypy est pour l'instant lancé avec cpython, donc il est forcément plus lent :)
Non, c'était justement quand PyPy était interprété par CPython qu'il était plusieurs centaines de fois plus lent. Maintenant PyPy est traduit en C puis compilé par gcc pour arriver à être "à peine" 3x plus lent que CPython. La page suivante présente les perfs selon le mode de compilation (C, LLVM, etc.) :
http://tuatara.cs.uni-duesseldorf.de/benchmark.html
PyPy .NET est 70x plus lent que CPython :-p
-
Question de profane total
De ce que je viens de lire au sein des commentaires,
ceci servirait notamment à convertir un code d'un langage en un autre.
Existe-t-il un programme qui pourrait convertir tous ces langages de programmation (C, python, etc...) en assembleur (le langage, finalement dit le plus proche de la machine ?).
Juste une question candide.
Ne vous déchaînez pas sur moi :)
http://nikoolinux.zeblog.com/
-
[^]Re: Question de profane total
Posté par Aurélien Girard () le 22/02/2007 à 12:50. (lien). Évalué à 10.Tous je ne sais pas mais un bon paquet oui, ce logiciel existe. Son nom : http://gcc.gnu.org/ .
-
[^]Re: Question de profane total
Posté par Nikoo () le 22/02/2007 à 13:03. (lien). Évalué à 4.Merde....question de buse, désolé, je viens de revoir la définition de compilateur...
Mais alors dans ce cas, quel est l'intérêt de programmer directement en assembleur ?--
http://nikoolinux.zeblog.com/-
[^]Re: Question de profane total
Posté par Bastoon (Jabber id, page perso, ) le 22/02/2007 à 13:21. (lien). Évalué à 4.Bonjour,
Parfois le compilateur n'arrive pas à optimiser le code assembleur de la même façon qu'un humain l'aurais produit. La programmation en assembleur a aussi existé avant l'arrivée des compilateurs. On remarquera que les erreurs sont vites arrivées et que la maintenance du code est quasi-nulle ...
Après l'intérêt peut-être pédagogique... ou pour développer des compilateurs (bien qu'ils soient souvent développés dans un autre langage plus haut niveau).--
Bastoon
-
[^]Re: Question de profane total
Posté par TheBreton () le 22/02/2007 à 13:58. (lien). Évalué à 6.En général sur PC c'est un mode de fonctionnement qui à été abandonné depuis quelques temps. Dans mon cas (soft embarqué avec des petits micro 8 ou 16bits) la régle est
-Le micro passe 80% de sont temps dans 20% du code
c'est généralement vrai, donc l'optimisation ultime est d'identifier les 20% de code et de ré-écrire ces 20% en assembleur permet d'obtenir des resultats bluffants (j'ai deja vu des 400% de gains de temps de traitement).Il est tres simple d'interfacer l'assembleur avec le C (mais il faut s'astreindre à une version particulière de compilateur pour ne pas avoir de surprise).
Le langage C est tres proche du materiel, avec une bonne habitude de ton compilateur tu peut prevoir comment il traduira en assembleur ce que tu est en train d'ecrire et produire un code avec une bonne optimisation de base.--
Merde, ca fait trois fois que je le coupe il est toujours trop court!
-(un stagiaire hardware qui devait connaitre le grand pere de Sylvain Sauvage ;-) )--
[^]Re: Question de profane total
Posté par Nikoo () le 24/02/2007 à 11:59. (lien). Évalué à 2.En complément de ces précisions, je tiens à faire de la pub pour MenuetOS, écrit en assembleur et qui tient sur une disquette apparemment :
http://www.menuetos.net/--
http://nikoolinux.zeblog.com/
-
[^]Re: Question de profane total
Posté par imalip (page perso, ) le 26/02/2007 à 10:05. (lien). Évalué à 2.Et j'ajouterai que parfois, il y a des bouts de code pour lesquels on n'a pas forcement envie de voir un compilo essayer d'optimiser, et ou l'on veut decider exactement ce que fait la machine.
Genre un bootloader sur TigerSharc qui tient en 256 instructions max et doit finir par lancer un DMA pour se remplacer par le vrai executable puis enchainer par un branch a l'adresse qui va bien.--
"While a monkey can be a manager, it takes a human to be an engineer" Erik Zapletal
-
-
-
Impossible?
Ce projet et les objectifs annoncés semblent déments... En effet, nous apprenons dès nos début en programmation que plus un langage est "haut niveau" et plus ses performances sont dégradées (en général). De la même façon, nous apprenons (et vérifions) que les langages interprétés sont généralement plus lents que les langages compilés. Les objectifs de ce projet, s'ils sont atteints, viendraient bousculer notre conception de la programmation "efficace".
Par ailleurs, cela fait quelques temps que Python et Scipy/Numpy est utilisable pour faire de la simulation numérique. À présent, on peut espérer voir un interpréteur Python optimisé pour le calcul massivement parallèle, ou encore avec des déclarations de type évoluées.
Python est de plus en plus prometteur, et ça faire plaisir de voir de l'argent européen investit dans un tel projet.
En résumé: Python, c'est bon!
-
[^]Re: Impossible?
Posté par Albert () le 22/02/2007 à 15:55. (lien). Évalué à 2.le probleme c'est que scipy/numpy c'est du CPython uniquement et vu la quantite de boulot fournit par Travis Oliphant pour faire ca ca risque de pas etre simple de reoptimiser en pure python... surtout que la tendance est de transformer en C les partis en python pour accelerer la chose.
-
[^]Re: Impossible?
Posté par Gilles G. () le 22/02/2007 à 16:41. (lien). Évalué à 2.Ah bon?
Tu veux dire que les extensions en C ne seront pas utilisable avec un interpréteur PyPy construit en C par PyPy lui-même? Pourquoi est-ce que du C ne serait pas compatible avec du C?
Je m'emmèle peut-être les pinceaux, mais moi ce que j'ai compris c'est que PyPy permet de fabriquer le code C d'un interpréteur Python lui même très rapide pour l'interprétation du code Python. Après, les extensions en C, ben ça reste du C.
A la fin, un interpréteur Python, c'est capable d'utiliser des modules C ou Fortran, ou autre. C'est justement la force de Python. Je vois pas pourquoi ils s'en passeraient.-
[^]Re: Impossible?
-
[^]Re: Impossible?
Posté par Troy McClure (page perso, ) le 25/02/2007 à 16:23. (lien). Évalué à 3.oui mais les extensions elles utilisent l'api CPython, celle qui est décrite là http://docs.python.org/api/api.html et qui n'est bien sur pas celle utilisée par pypy, donc vraisemblablement tout sera à refaire..
-
-
-
[^]Re: Impossible?
Posté par Papa Furax (page perso, ) le 22/02/2007 à 18:49. (lien). Évalué à 2.En fait si j'ai bien compris c'est comme pour la JVM:
ce qui est le plus prometteur c'est le JIT, car ça permet de compiler le code en effectuant des optimisation que l'on ne peux pas faire avec les langages compilés classiques (qui génère du code objet).
Comme par exemple de compiler avec des optimisation spécifique à la machine et à l'OS, ou la prévision des branchements, en utilisant des infos disponible à l'exécution.
-
[^]Re: Impossible?
Posté par Matthieu C () le 22/02/2007 à 20:19. (lien). Évalué à 4.En effet, nous apprenons dès nos début en programmation que plus un langage est "haut niveau" et plus ses performances sont dégradées (en général).
Gnome est lent, ils auraient du coder en assembleur :)
Plus serieusement, plus le langage est bas niveau, plus il est possible de faire un truc hyper performant ou un truc mega lent (si on loupe des optimisations qu'un compilo aurait vu).
De la même façon, nous apprenons (et vérifions) que les langages interprétés sont généralement plus lents que les langages compilés.
Avec la compilation JIT, les langages interprétés doivent pouvoir etre plus rapide que leur equivalent compilé dans certains cas.
Voir par exemple un scaler compilé en JIT, plus rapide que son equivalent C compilé statiquement : http://thread.gmane.org/gmane.comp.video.ffmpeg.devel/42975-
[^]Re: Impossible?
Posté par Victor STINNER (page perso, ) le 23/02/2007 à 09:24. (lien). Évalué à 1.Avec la compilation JIT, les langages interprétés doivent pouvoir etre plus rapide que leur equivalent compilé dans certains cas.
Hum, je pense que ce n'est sûrement pas vrai dans tous les cas. Je pense plutôt qu'étant donné qu'un programme Python est bien plus court (en nombre de lignes), on peut passer plus de temps à réécrire l'algorithme / faire des tests.
-
[+] Ca c'est une révolution
Cette page a été générée par Templeet en 0.1674s (dont 0.0161 de SQL).
Cette page est peut-être conforme xhtml 1.0.
Information sur le site.
Faire un don !
Cette discussion est archivée, il n'est plus possible de laisser des commentaires.
Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.