Plus rapide que la version officielle et moins gourmande en mémoire, elle permet de réaliser des exécutables et des dll's utilisables par les autres langages compilables pour CLR (type C#, VB, ...).
NdM : l'auteur de IronPython, Jim Hugunin, s'était déjà illustré en créant Jython (une implémentation de Python pour Java), et en participant activement aux développements de Numerical Python et d'AspectJ. Il a récemment rejoint l'équipe CLR de Microsoft, où il compte poursuivre son travail sur IronPython et promouvoir l'utilisation sur cette plate-forme des langages dynamiques en général. Cette implémentation met en avant :
La rapidité :
La version 0.6 est plus de 1.7 fois plus rapide que Python 2.3 (selon le benchmark PyStone)
La réutilisabilité :
Il est possible d'utiliser/dériver les bibliothèques disponibles pour CLR, y compris celles écrites dans d'autres langages que Python.
L'interprétation dynamique :
IronPython supporte l'interprétation du code et sa compilation (transparente) à la volée, tout comme Python lui-même.
La compilation statique :
Il supporte aussi la compilation statique, produisant des exécutables (.exe) ou de librairies (.dll) pouvant être utilisé par des langages supportant CLR comme C#, VB, ...
Il est toutefois important de noter que c'est une version 0.6 (alpha) à ne pas utiliser en production.
Aller plus loin
- Site officiel (18 clics)
- Présentation à PyCon (mars 2004) (3 clics)
- Site de l'auteur (3 clics)
- CLR Tutorial (8 clics)
# comparaisons...
Posté par cedricv . Évalué à 2.
donc de 1 à plus de 10 fois moins rapide que Python+Psyco?
(vu qu'un code Python important Psyco est en général 3 à 10 fois plus rapide qu'un code Python 'Nu')
[^] # Re: comparaisons...
Posté par tgl . Évalué à 3.
[^] # Re: comparaisons...
Posté par cedricv . Évalué à -1.
bon par contre ("Sorry, no other processor is supported yet."), ce n'est pas du tout avancé.
mais cela ouvre une nouvelle question: quid des perfs IronPython+Psyco? :-)
[^] # Re: comparaisons...
Posté par TazForEver . Évalué à 4.
[^] # Re: comparaisons...
Posté par cedricv . Évalué à -1.
[^] # Re: comparaisons...
Posté par tgl . Évalué à 4.
Oui, c'est ce que je dis. Y'a rien d'entamé, ni de sérieusement prévu à ma connaissance. Évidemment que dans l'absolu on peut faire la même chose sur d'autres archis, mais ça n'est pas près d'arriver.
Alors que pour CLR, c'est d'une part beaucoup plus intéressant de le faire (tu fais d'une pierre 36 coups, enfin autant qu'il y a de langages compilables en bytecode CLR), et d'autre part déjà largement entamé (je parlais de "bien entamé sur PPC", mais c'est en fait carrément bel et bien fait, et sur Sparc aussi).
quid des perfs IronPython+Psyco? :-)
Ouf, il y a un smiley.
[^] # Re: comparaisons...
Posté par TazForEver . Évalué à 10.
http://advogato.org/person/TazForEver/diary.html?start=7(...)
en gros c'est inimaginablement lent, les types de bases du langage sont défaillants (mon benchmark échoue, {}.copy() n'est pas implémenté, etc, etc, très peu de fonctions intégrées sont implémentées (open/file sont absents/défaillants, etc ...)
bref beaucoup de bruit pour rien, ça sert à rien de faire une annonce publique pour un projet qui balbutie. Ce n'est pas qu'IronPython ne soit pas stable et donc pas destiné à un environnement de production : c'est qu'il est creux, vide.
[^] # Re: comparaisons...
Posté par Lafrite . Évalué à 4.
Y'a beaucoups de niouzes pour les pré alpha sur linuxfr 8-)
# Pas de bibliothèques
Posté par Nicolas Évrard (site web personnel) . Évalué à 0.
M'enfin ce n'est qu'une 0.6, ça devrait avancer plus vite maintenant que Jim Hugunin va bosser chez microsoft.
[^] # Re: Pas de bibliothèques
Posté par TazForEver . Évalué à 8.
La conclusion constructive, c'est qu'il est temps de définir une API indépendante pour GTK (ou autre) pour python, perl, ruby, sinon ça ne sert strictement à rien. Ils faut que les développeurs se mettent d'accord.
[^] # Re: Pas de bibliothèques
Posté par Narishma Jahar . Évalué à 2.
# Branlette, FUD, ...
Posté par TazForEver . Évalué à 7.
on va faire au ressenti.
lancer l'interpréteur python, taper 'dir()'
faites le avec IronPython ou CPython, c'est quoi votre impression ?
Perso, je vois PyStone, c'est bidon. Je m'en fiche bien que l'invocation de méthode soit plus rapide si le corps de ma méthode si simple soit il, s'exécute 10 plus lentement. Le benchmark que je donne est simplissime, IronPython prends une raclé. C'est simple au début je le tuais, voyant Pyso mettre 6s, au bout de 30s je croyais qu'IronPython avait planté ...
[^] # Re: Branlette, FUD, ...
Posté par bmc . Évalué à 1.
À moins que ce soit sur /var/log/ksymoops, je ne vois pas... ou que dir() ne fasse pas du tout ce qu'intuitivement je pense qu'il fait... ou encore que la machine de test soit un veau
[^] # Re: Branlette, FUD, ...
Posté par TazForEver . Évalué à 2.
- du premier contact avec le shell interactif,dir() étant une fonction de base de python, un truc souvent utilisé. un truc aussi bateau que ls. imagine, on te dis 'oua ce shell est vachement rapide et bouffe moins de ram que bash', toi, pépère, tu le lances, tu tapes ls machinalement ...grrrrrrrrr (grattement disque) ... 1 bonne seconde plus tard, tu ton liste de fichiers
- d'un benchmark (travail sur des chaines de caractères, jouons avec les séquence d'ADN). (je continue pas le parallèle là)
Que ce soit au ressenti ou avec un benchmark, IronPython est affreusement long.
[^] # Re: Branlette, FUD, ...
Posté par Alexandre Boeglin . Évalué à 2.
En python, dir() te permet d'afficher une liste de toutes les méthodes et arguments de l'objet* sur lequel tu l'appelles
* : qui peut être un type, une variable, une classe, une instance, un module...
c'est super pratique en mode interactif si tu ne sais plus comment s'appelle telle méthode, ou quelles sont les possibilités de tel autre type que te retourne une fonction, mais ca sert pas à grand chose dans un script, je pense...
et je vois surtout pas sur quoi tu peux bien faire un dir() pour qu'il mette 6 secondes à t'afficher la liste...
[^] # Re: Branlette, FUD, ...
Posté par TazForEver . Évalué à 3.
# Peut-être aurait-il été utile de préciser que...
Posté par TImaniac (site web personnel) . Évalué à 1.
Le but n'est donc pas de concurrencer Python lui-même, le but est d'offrir une syntaxe supplémentaire et une possibilité d'interprétation dynamique au dessus de Mono/.NET.
Pour ce qui est de la rapidité, il faut relativiser : certaines fonctions vont tourner 10 fois plus rapidement (ceux qui sont fan de IronPython les utiliseront dans leurs tests) d'autres c'est l'inverse (et évidemment les détracteur s'empresseront de les montrer comme exemple). Ensuite sous Linux ce n'est utilisable que sous Mono, et de l'aveu même du concepteur c'est nettement plus lent que sur la machine .NET de Microsoft.
En tout cas ce projet a atteint son but : montrer qu'il était possible d'utiliser un langage dynamique sous .NET malgrès ce que de petits malin ont affirmé en faisant une implentation bidon de Python. Le fait que son auteur soit embauché dans l'équipe du CLR de Microsoft peut laisser présager des modifications dans le code intermédiaire IL de la VM .NET pour faciliter l'intégration de ces langages.
[^] # Re: Peut-être aurait-il été utile de préciser que...
Posté par Philippe F (site web personnel) . Évalué à 4.
Tu parles peut-etre de l'implementation realisee par Mark Hammond un des gourou de la communaute python, implementation financee par Microsoft ?
Dans ce cas, je remballerai l'experssion "petits malins". Mark Hammond est extremement respecte dans la communaute python et il y a des raisons pour lesquelles son implementaiton n 'etait pas optimale, que Guido van Rossum detaille dans mon interview (http://www.freehackers.org/fosdem2002/guido.html(...)):
<<
Anyway, they did a Python port to .NET very early on, with some funding from Microsoft. I think the issue was mostly for Microsoft to show that Common Language Runtime really was a suitable target for multiple languages because they did the same thing with lot of language groups. [...] It's true that the Python .NET interpreter is very slow. I think part of that is just that they didn't have enough time to make it faster, there is always optimisations. The other thing was beacuase they did it so early on that they had to sign very strict Non Disclosure Agreements and Mark Hammond couldn't ask anyone for help because he was on NDA. He couldn't tell anybody even that he was working on this project until it was finished. So if he didn't know the compiler techniques, he was basically on his own. And there was also not much documentation about .NET available at that point, because .NET was basically still a Microsoft internal project. So I think now, this is based on a few things that Miguel told me actually. There are number of approaches to make it much faster.
>>
[^] # Re: Peut-être aurait-il été utile de préciser que...
Posté par TImaniac (site web personnel) . Évalué à 2.
Euh, je parlais de l'implentation de ActiveState, peut-être est-ce la même ? En tout leur conclusion montrait que .NET n'était pas fait pour un langage dynamique.
Ton interview tend effectivement à montrer les véritables causes de cette leuteur dans certains prototypes.
Sinon j'ai trouvé un point positif dans IronPython, qui n'a pas grand chose à voir avec le langage en soit : son créateur n'a pas testé son interpréteur sous Linux, et pour avoir essayé celà marche très bien, sans rien recompiler, sans rien installer (à part Mono bien sûr) : un bon exemple d'interopérabilité et d'abstraction de l'OS/distri, un peu comme en Java.
[^] # Re: Peut-être aurait-il été utile de préciser que...
Posté par Jerome Alet (site web personnel) . Évalué à 2.
> en Java.
trop cool !!
moi qui me faisait chier à écrire deux versions de mes prog Python, une pour *nix et une pour *indows !
Putain, faut arrêter de fumer la moquette, java ou machin# ne révolutionnent rien
[^] # Re: Peut-être aurait-il été utile de préciser que...
Posté par TImaniac (site web personnel) . Évalué à 2.
Et puis la portabilité de Python est quand même en grosse partie due au fait que tu te balade avec les sources, pas avec un code machine ;)
[^] # Re: Peut-être aurait-il été utile de préciser que...
Posté par Jerome Alet (site web personnel) . Évalué à 2.
rails de coke sucks, champignons hallu rules (et en plus c'est gratos, y'a qu'à se baisser pour les ramasser)
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.