Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Jean-Marc Matline
Bonjour,
De quoi ai-je besoin pour tourner IronPython ? Et pour tourner un programme écrit avec IronPython ? Existe t'il un petit tutorial pour debuter avec IronPython ?
Merci
"MCI"; "Shadok Gouroudoudou" a écrit dans le message de news:
Bonjour !
La version 2.0 Alpha-1 est sortie.
C'est là : http://www.codeplex.com/IronPython/Release/ProjectReleases.aspx?ReleaseIdC8
La principale nouveauté, c'est que cette version cible Python 2.5
-- @-salutations
Michel Claveau
Bonjour,
De quoi ai-je besoin pour tourner IronPython ?
Et pour tourner un programme écrit avec IronPython ?
Existe t'il un petit tutorial pour debuter avec IronPython ?
Merci
"MCI"; "Shadok Gouroudoudou" <pas.de@spam.svp> a écrit dans le message de
news:mn.09db7d758685922d.34209@spam.svp...
Bonjour !
La version 2.0 Alpha-1 est sortie.
C'est là :
http://www.codeplex.com/IronPython/Release/ProjectReleases.aspx?ReleaseIdC8
La principale nouveauté, c'est que cette version cible Python 2.5
De quoi ai-je besoin pour tourner IronPython ? Et pour tourner un programme écrit avec IronPython ? Existe t'il un petit tutorial pour debuter avec IronPython ?
Merci
"MCI"; "Shadok Gouroudoudou" a écrit dans le message de news:
Bonjour !
La version 2.0 Alpha-1 est sortie.
C'est là : http://www.codeplex.com/IronPython/Release/ProjectReleases.aspx?ReleaseIdC8
La principale nouveauté, c'est que cette version cible Python 2.5
-- @-salutations
Michel Claveau
MCI, Shadok Gouroudoudou
Bonsoir !
Y'a tout ce qu'il faut sur le site (il suffit de cliquer sur l'onglet "Home".
Par ailleurs, un petit tutorial est inclu dans le tétéchargement.
En gros, il faut : le framework dotNET 1.1 + un éditeur ; c'est tout.
-- @-salutations
Michel Claveau
Bonsoir !
Y'a tout ce qu'il faut sur le site (il suffit de cliquer sur l'onglet
"Home".
Par ailleurs, un petit tutorial est inclu dans le tétéchargement.
En gros, il faut : le framework dotNET 1.1 + un éditeur ; c'est tout.
Pour les 100 balles et le Mars, via usenet, ça ne passe pas...
-- [Attention : « vote OUI [resp. NON] pour fr.comp.os.linux » signifie pour [resp. contre] la _suppression_ de fr.comp.os.linux.] [...] Ceci est une réponse automatique à votre vote. -+- CM in: Guide du linuxien pervers - Roby le robot rame et radote -+-
Pour les 100 balles et le Mars, via usenet, ça ne passe pas...
--
[Attention : « vote OUI [resp. NON] pour fr.comp.os.linux » signifie
pour [resp. contre] la _suppression_ de fr.comp.os.linux.]
[...] Ceci est une réponse automatique à votre vote.
-+- CM in: Guide du linuxien pervers - Roby le robot rame et radote -+-
Pour les 100 balles et le Mars, via usenet, ça ne passe pas...
-- [Attention : « vote OUI [resp. NON] pour fr.comp.os.linux » signifie pour [resp. contre] la _suppression_ de fr.comp.os.linux.] [...] Ceci est une réponse automatique à votre vote. -+- CM in: Guide du linuxien pervers - Roby le robot rame et radote -+-
Pour les 100 balles et le Mars, via usenet, ça ne passe pas...
Bien sûr, j'aurais pu trouver cela par moi-même.
Je m'attendais plutôt à un réel retour d'expérience.
Tiens, une question: Qu'apporte .net+IronPython de plus ou de moins que CPython+PyWin32 en termes de fonctionnalités, de perf et de facilité d'interaction avec les composantes Windows?
On 2 mai, 11:47, Eric Masson <e...@free.fr> wrote:
Pour les 100 balles et le Mars, via usenet, ça ne passe pas...
Bien sûr, j'aurais pu trouver cela par moi-même.
Je m'attendais plutôt à un réel retour d'expérience.
Tiens, une question:
Qu'apporte .net+IronPython de plus ou de moins que CPython+PyWin32
en termes de fonctionnalités, de perf et de facilité d'interaction
avec les composantes Windows?
Pour les 100 balles et le Mars, via usenet, ça ne passe pas...
Bien sûr, j'aurais pu trouver cela par moi-même.
Je m'attendais plutôt à un réel retour d'expérience.
Tiens, une question: Qu'apporte .net+IronPython de plus ou de moins que CPython+PyWin32 en termes de fonctionnalités, de perf et de facilité d'interaction avec les composantes Windows?
Eric Masson
olive writes:
'Re,
Qu'apporte .net+IronPython de plus ou de moins que CPython+PyWin32 en termes de fonctionnalités, de perf et de facilité d'interaction avec les composantes Windows?
Pywin32 est un wrapper python sur l'api win32 alors qu'IronPython est un langage qui permet d'utiliser les fonctionnalités de la plateforme .Net
Pour une description plus détaillée du framework en version 1.1 : http://www.dotnet-fr.org/sections.php3?op=viewarticle&artid=1 http://www.dotnet-fr.org/sections.php3?op=viewarticle&artid4
Pour les versions ultérieures, developpez.com, codeproject ou le msdn sont des mines d'information.
La homepage d'IronPython fournit des éléments de réponse sur les différences entre cpython et IronPython : http://www.codeplex.com/Wiki/View.aspx?ProjectName=IronPython
.Net est la la technologie poussée par Microsoft pour le développement d'applications sur plateforme Windows, certains services disponibles sur les dernières versions de Windows ne sont pas accessibles autrement que via .Net (les nouveautés du framework 3.0 par exemple)
-- Qui peut m'expliquer comment fonctionne le fusible thermique sur les processeurs. Est ce que cela peut se configurer ? -+- DA in : <http://www.le-gnu.net> : Neuneu pète un plomb -+-
olive <ocollioud@gmail.com> writes:
'Re,
Qu'apporte .net+IronPython de plus ou de moins que CPython+PyWin32
en termes de fonctionnalités, de perf et de facilité d'interaction
avec les composantes Windows?
Pywin32 est un wrapper python sur l'api win32 alors qu'IronPython est un
langage qui permet d'utiliser les fonctionnalités de la plateforme .Net
Pour une description plus détaillée du framework en version 1.1 :
http://www.dotnet-fr.org/sections.php3?op=viewarticle&artid=1
http://www.dotnet-fr.org/sections.php3?op=viewarticle&artid4
Pour les versions ultérieures, developpez.com, codeproject ou le msdn
sont des mines d'information.
La homepage d'IronPython fournit des éléments de réponse sur les
différences entre cpython et IronPython :
http://www.codeplex.com/Wiki/View.aspx?ProjectName=IronPython
.Net est la la technologie poussée par Microsoft pour le développement
d'applications sur plateforme Windows, certains services disponibles sur
les dernières versions de Windows ne sont pas accessibles autrement que
via .Net (les nouveautés du framework 3.0 par exemple)
--
Qui peut m'expliquer comment fonctionne le fusible thermique sur les
processeurs. Est ce que cela peut se configurer ?
-+- DA in : <http://www.le-gnu.net> : Neuneu pète un plomb -+-
Qu'apporte .net+IronPython de plus ou de moins que CPython+PyWin32 en termes de fonctionnalités, de perf et de facilité d'interaction avec les composantes Windows?
Pywin32 est un wrapper python sur l'api win32 alors qu'IronPython est un langage qui permet d'utiliser les fonctionnalités de la plateforme .Net
Pour une description plus détaillée du framework en version 1.1 : http://www.dotnet-fr.org/sections.php3?op=viewarticle&artid=1 http://www.dotnet-fr.org/sections.php3?op=viewarticle&artid4
Pour les versions ultérieures, developpez.com, codeproject ou le msdn sont des mines d'information.
La homepage d'IronPython fournit des éléments de réponse sur les différences entre cpython et IronPython : http://www.codeplex.com/Wiki/View.aspx?ProjectName=IronPython
.Net est la la technologie poussée par Microsoft pour le développement d'applications sur plateforme Windows, certains services disponibles sur les dernières versions de Windows ne sont pas accessibles autrement que via .Net (les nouveautés du framework 3.0 par exemple)
-- Qui peut m'expliquer comment fonctionne le fusible thermique sur les processeurs. Est ce que cela peut se configurer ? -+- DA in : <http://www.le-gnu.net> : Neuneu pète un plomb -+-
olive
On 2 mai, 14:19, Eric Masson wrote:
certains services disponibles sur les dernières versions de Windows ne sont pas accessibles autrement que via .Net (les nouveautés du framework 3.0 par exemple)
OK, je commence à y voir plus clair.
Dois-je comprendre que IronPython n'est pas supporté par les versions de .net supérieures à 1.1 ?
Est-ce IronPython qui a du retard ou bien est-ce parceque seules les .net >= 1.1 sont téléchargeables ?
On 2 mai, 14:19, Eric Masson <e...@free.fr> wrote:
certains services disponibles sur
les dernières versions de Windows ne sont pas accessibles autrement que
via .Net (les nouveautés du framework 3.0 par exemple)
OK, je commence à y voir plus clair.
Dois-je comprendre que IronPython n'est pas supporté par les versions
de .net supérieures à 1.1 ?
Est-ce IronPython qui a du retard ou bien est-ce parceque seules
les .net >= 1.1 sont téléchargeables ?
certains services disponibles sur les dernières versions de Windows ne sont pas accessibles autrement que via .Net (les nouveautés du framework 3.0 par exemple)
OK, je commence à y voir plus clair.
Dois-je comprendre que IronPython n'est pas supporté par les versions de .net supérieures à 1.1 ?
Est-ce IronPython qui a du retard ou bien est-ce parceque seules les .net >= 1.1 sont téléchargeables ?
Eric Masson
olive writes:
'Re,
Dois-je comprendre que IronPython n'est pas supporté par les versions de .net supérieures à 1.1 ?
La version 2.0 Alpha dont parlait le sieur Claveau semble avoir besoin d'un framework 2.0 pour fonctionner (pas du tout regardé pour le moment)
Est-ce IronPython qui a du retard ou bien est-ce parceque seules les .net >= 1.1 sont téléchargeables ?
Le support officiel des langages dynamiques dans .Net est tout récent... Ceci explique probablement cela.
-- «je vous savoire comment faire lancer un programme ,qui a comme resultat devenire root , une fois il est executer.» LD in Guide du linuxien pervers - "Petit lamer deviendra grand... peut-être"
olive <ocollioud@gmail.com> writes:
'Re,
Dois-je comprendre que IronPython n'est pas supporté par les versions
de .net supérieures à 1.1 ?
La version 2.0 Alpha dont parlait le sieur Claveau semble avoir besoin
d'un framework 2.0 pour fonctionner (pas du tout regardé pour le moment)
Est-ce IronPython qui a du retard ou bien est-ce parceque seules
les .net >= 1.1 sont téléchargeables ?
Le support officiel des langages dynamiques dans .Net est tout récent...
Ceci explique probablement cela.
--
«je vous savoire comment faire lancer un programme ,qui a comme resultat
devenire root , une fois il est executer.»
LD in Guide du linuxien pervers - "Petit lamer deviendra grand... peut-être"
Dois-je comprendre que IronPython n'est pas supporté par les versions de .net supérieures à 1.1 ?
La version 2.0 Alpha dont parlait le sieur Claveau semble avoir besoin d'un framework 2.0 pour fonctionner (pas du tout regardé pour le moment)
Est-ce IronPython qui a du retard ou bien est-ce parceque seules les .net >= 1.1 sont téléchargeables ?
Le support officiel des langages dynamiques dans .Net est tout récent... Ceci explique probablement cela.
-- «je vous savoire comment faire lancer un programme ,qui a comme resultat devenire root , une fois il est executer.» LD in Guide du linuxien pervers - "Petit lamer deviendra grand... peut-être"
Méta-MCI
Bonjour !
Je vais compléter, à ma façon, les propos d' Eric Masson, qui a, déjà, bien déblayé le terrain.
dotNET, c'est une surcouche de Windows (ou de Linux, avec Mono). Cette surcouche, est essentiellement fonctionnelle, et est constituée de milliers de classes et de méthodes, agencées selon une hiérarchie (par héritage) plutôt complexe (AMHA).
Le framework dotNET est l'ensembles des classes/méthodes d'exécution de dotNET. Il existe, pour les PC, en 3 versions : 1.1, 2.0, 3.0 (il existe des versions pour mobiles, pour embarqué, etc.) ; toutes ces versions peuvent coexister.
Un problème, c'est que tout ça a été construit sur du typage statique. Du coup, quand on utilise une classe (après l'avoir trouvée), on est obligé de chercher, et de remonter la hiérarchie, pour voir les conditions d'appels, de paramètres, etc. On voit souvent, dans les forums, des développeurs qui demandent pourquoi ça ne marche pas, et qq répondre : "ta classe machin hérite de titi, qui hérite de grosminet, qui a besoin d'un paramètre de tel type..." et "pour convertir ton paramètre dans ce type, il faut que tu instancies cette autre classe, qui hérite de ceci ou cela, et que tu utilises la méthode truc" ;
Bref, c'est lourd. Très lourd. L'IDE de MS, Visual-studio, fait beaucoup de choses pour améliorer l'usine, mais, du coup, il est devenu lui-même assez lourd (presque autant qu'Eclipse), et il a quelques problèmes (bogues).
Il faut quand même savoir que Visual-Studio intègre beaucoup de fonctionnalités. De l'édition du code source, à la distribution des logiciels finis, en passant par la gestion des projets (multi-développeurs), les signatures, les cryptages, la gestion des versions, le déboguage, le déploiement, la sécurité, la compression, la génération des docs, la génération de multiples formes du résultat final, etc. etc.
Jim Hugunin, le créateur d' IronPython, a réussi a contourner la plupart des problèmes d'utilisation d'un système statique, pour faire un langage dynamique (il est fort, le bougre).
Il faut savoir que, dans dotNET, le moteur d'exécution (machine virtuelle), baptisé CLR (Common Language Runtime) est utilisé par tous les langages. Il traduit tous les programmes et autres scripts en un langage intermédiaire, le MSIL (MicroSoft Intermediate Language). Cette traduction est faite par une compilation JIT (Just In Time).
Sans doute un peu gêné quand même, J.H. a travaillé sur un truc particulier, la DLR (Dynamic Language Runtime), qui est une extension de la CLR, dédiée aux langages dynamiques. Les langages suivants sont annoncés : ironPython, Javascript, Ruby, VB (les deux premiers étant dispo).
La sortie officielle de la DLR est très récente, et a accompagné la sortie de SilverLight (qui est d'ores et déjà programmable en ironPython et Javascript)
SilverLight ?
Il faut d'abord revenir sur l'interface graphique de Vista, baptisée Avalon. Cette interface est graphique, vectorielle, et utilise abondamment les cartes graphiques accélérée (via Direct-X). Les éléments de l'interface sont décrits dans un dialecte XML : XAML (un peu comme HTML pour le web graphique). AMHA, on retrouve le même problème avec XAML : typage statique et compilation, ce qui rend lourd les développements.
Par ailleurs, MS voulait concurrencer Flash, en utilisant dotNET. Pour cela, ils ont développé un plug-in pour navigateurs (Internet-Explorer, Safari, et, avec quelques restrictions, Firefox). Ce plug-in, c'est SilverLight ; il permet d'utiliser XAML de façon dynamique (enfin, c'est ce qui est dit).
Jim Hugunin a travaillé sur SilverLight, et a permit de d'y utiliser ironPython (et Javascript). Normalement, tous les langages de dotNET devraient pouvoir l'utiliser.
Petit détail : les quelques exemples fournis fonctionnent aussi bien via le web que par chargement d'un fichier local.
Différences IronPython et CPython.
dotNET contient de nombreuses classe/méthodes, qui recouvrent de nombreux besoins, dans de nombreux secteurs. Et cela entre en concurrence directe avec la librairie standard de Python. IronPython a accès à toutes ces librairies. Dès lors, la question s'est posée, de choisir entre utiliser les possibilités de dotNET, et développer les adaptations nécessaires dans la librairie standard. La même question se pose aux utilisateurs d'ironPython, pour des fonctions qui existent à la fois dans dotNET et dans la librairie standard. Et, il n'y a pas de réponse universelle et simple, d'autant plus que, en passant par dotNET, IronPython a accès à toutes les librairies développées dans les autres langages (C#, J#, F#, VB.Net, C++.Net, Delphi.Net, etc.)
PythonNET
Il existe une autre voie : PythonNET. Là, on est du côté CPython (le Python normal, quoi), avec la possibilité d'appeler des éléments de dotNET. En gros, PythonNET utilise dotNET de l'extérieur, alors que IronPython travaille de l'intérieur.
Voilà un résumé de la situation.
@+
MCI
Bonjour !
Je vais compléter, à ma façon, les propos d' Eric Masson, qui a, déjà, bien
déblayé le terrain.
dotNET, c'est une surcouche de Windows (ou de Linux, avec Mono). Cette
surcouche, est essentiellement fonctionnelle, et est constituée de milliers
de classes et de méthodes, agencées selon une hiérarchie (par héritage)
plutôt complexe (AMHA).
Le framework dotNET est l'ensembles des classes/méthodes d'exécution de
dotNET. Il existe, pour les PC, en 3 versions : 1.1, 2.0, 3.0 (il existe
des versions pour mobiles, pour embarqué, etc.) ; toutes ces versions
peuvent coexister.
Un problème, c'est que tout ça a été construit sur du typage statique. Du
coup, quand on utilise une classe (après l'avoir trouvée), on est obligé de
chercher, et de remonter la hiérarchie, pour voir les conditions d'appels,
de paramètres, etc. On voit souvent, dans les forums, des développeurs qui
demandent pourquoi ça ne marche pas, et qq répondre : "ta classe machin
hérite de titi, qui hérite de grosminet, qui a besoin d'un paramètre de tel
type..." et "pour convertir ton paramètre dans ce type, il faut que tu
instancies cette autre classe, qui hérite de ceci ou cela, et que tu
utilises la méthode truc" ;
Bref, c'est lourd. Très lourd. L'IDE de MS, Visual-studio, fait beaucoup de
choses pour améliorer l'usine, mais, du coup, il est devenu lui-même assez
lourd (presque autant qu'Eclipse), et il a quelques problèmes (bogues).
Il faut quand même savoir que Visual-Studio intègre beaucoup de
fonctionnalités. De l'édition du code source, à la distribution des
logiciels finis, en passant par la gestion des projets (multi-développeurs),
les signatures, les cryptages, la gestion des versions, le déboguage, le
déploiement, la sécurité, la compression, la génération des docs, la
génération de multiples formes du résultat final, etc. etc.
Jim Hugunin, le créateur d' IronPython, a réussi a contourner la plupart des
problèmes d'utilisation d'un système statique, pour faire un langage
dynamique (il est fort, le bougre).
Il faut savoir que, dans dotNET, le moteur d'exécution (machine virtuelle),
baptisé CLR (Common Language Runtime) est utilisé par tous les langages. Il
traduit tous les programmes et autres scripts en un langage intermédiaire,
le MSIL (MicroSoft Intermediate Language). Cette traduction est faite par
une compilation JIT (Just In Time).
Sans doute un peu gêné quand même, J.H. a travaillé sur un truc particulier,
la DLR (Dynamic Language Runtime), qui est une extension de la CLR, dédiée
aux langages dynamiques. Les langages suivants sont annoncés : ironPython,
Javascript, Ruby, VB (les deux premiers étant dispo).
La sortie officielle de la DLR est très récente, et a accompagné la sortie
de SilverLight (qui est d'ores et déjà programmable en ironPython et
Javascript)
SilverLight ?
Il faut d'abord revenir sur l'interface graphique de Vista, baptisée Avalon.
Cette interface est graphique, vectorielle, et utilise abondamment les
cartes graphiques accélérée (via Direct-X).
Les éléments de l'interface sont décrits dans un dialecte XML : XAML (un
peu comme HTML pour le web graphique).
AMHA, on retrouve le même problème avec XAML : typage statique et
compilation, ce qui rend lourd les développements.
Par ailleurs, MS voulait concurrencer Flash, en utilisant dotNET. Pour cela,
ils ont développé un plug-in pour navigateurs (Internet-Explorer, Safari,
et, avec quelques restrictions, Firefox). Ce plug-in, c'est SilverLight ;
il permet d'utiliser XAML de façon dynamique (enfin, c'est ce qui est dit).
Jim Hugunin a travaillé sur SilverLight, et a permit de d'y utiliser
ironPython (et Javascript). Normalement, tous les langages de dotNET
devraient pouvoir l'utiliser.
Petit détail : les quelques exemples fournis fonctionnent aussi bien via le
web que par chargement d'un fichier local.
Différences IronPython et CPython.
dotNET contient de nombreuses classe/méthodes, qui recouvrent de nombreux
besoins, dans de nombreux secteurs. Et cela entre en concurrence directe
avec la librairie standard de Python.
IronPython a accès à toutes ces librairies. Dès lors, la question s'est
posée, de choisir entre utiliser les possibilités de dotNET, et développer
les adaptations nécessaires dans la librairie standard. La même question se
pose aux utilisateurs d'ironPython, pour des fonctions qui existent à la
fois dans dotNET et dans la librairie standard.
Et, il n'y a pas de réponse universelle et simple, d'autant plus que, en
passant par dotNET, IronPython a accès à toutes les librairies développées
dans les autres langages (C#, J#, F#, VB.Net, C++.Net, Delphi.Net,
etc.)
PythonNET
Il existe une autre voie : PythonNET. Là, on est du côté CPython (le Python
normal, quoi), avec la possibilité d'appeler des éléments de dotNET. En
gros, PythonNET utilise dotNET de l'extérieur, alors que IronPython
travaille de l'intérieur.
Je vais compléter, à ma façon, les propos d' Eric Masson, qui a, déjà, bien déblayé le terrain.
dotNET, c'est une surcouche de Windows (ou de Linux, avec Mono). Cette surcouche, est essentiellement fonctionnelle, et est constituée de milliers de classes et de méthodes, agencées selon une hiérarchie (par héritage) plutôt complexe (AMHA).
Le framework dotNET est l'ensembles des classes/méthodes d'exécution de dotNET. Il existe, pour les PC, en 3 versions : 1.1, 2.0, 3.0 (il existe des versions pour mobiles, pour embarqué, etc.) ; toutes ces versions peuvent coexister.
Un problème, c'est que tout ça a été construit sur du typage statique. Du coup, quand on utilise une classe (après l'avoir trouvée), on est obligé de chercher, et de remonter la hiérarchie, pour voir les conditions d'appels, de paramètres, etc. On voit souvent, dans les forums, des développeurs qui demandent pourquoi ça ne marche pas, et qq répondre : "ta classe machin hérite de titi, qui hérite de grosminet, qui a besoin d'un paramètre de tel type..." et "pour convertir ton paramètre dans ce type, il faut que tu instancies cette autre classe, qui hérite de ceci ou cela, et que tu utilises la méthode truc" ;
Bref, c'est lourd. Très lourd. L'IDE de MS, Visual-studio, fait beaucoup de choses pour améliorer l'usine, mais, du coup, il est devenu lui-même assez lourd (presque autant qu'Eclipse), et il a quelques problèmes (bogues).
Il faut quand même savoir que Visual-Studio intègre beaucoup de fonctionnalités. De l'édition du code source, à la distribution des logiciels finis, en passant par la gestion des projets (multi-développeurs), les signatures, les cryptages, la gestion des versions, le déboguage, le déploiement, la sécurité, la compression, la génération des docs, la génération de multiples formes du résultat final, etc. etc.
Jim Hugunin, le créateur d' IronPython, a réussi a contourner la plupart des problèmes d'utilisation d'un système statique, pour faire un langage dynamique (il est fort, le bougre).
Il faut savoir que, dans dotNET, le moteur d'exécution (machine virtuelle), baptisé CLR (Common Language Runtime) est utilisé par tous les langages. Il traduit tous les programmes et autres scripts en un langage intermédiaire, le MSIL (MicroSoft Intermediate Language). Cette traduction est faite par une compilation JIT (Just In Time).
Sans doute un peu gêné quand même, J.H. a travaillé sur un truc particulier, la DLR (Dynamic Language Runtime), qui est une extension de la CLR, dédiée aux langages dynamiques. Les langages suivants sont annoncés : ironPython, Javascript, Ruby, VB (les deux premiers étant dispo).
La sortie officielle de la DLR est très récente, et a accompagné la sortie de SilverLight (qui est d'ores et déjà programmable en ironPython et Javascript)
SilverLight ?
Il faut d'abord revenir sur l'interface graphique de Vista, baptisée Avalon. Cette interface est graphique, vectorielle, et utilise abondamment les cartes graphiques accélérée (via Direct-X). Les éléments de l'interface sont décrits dans un dialecte XML : XAML (un peu comme HTML pour le web graphique). AMHA, on retrouve le même problème avec XAML : typage statique et compilation, ce qui rend lourd les développements.
Par ailleurs, MS voulait concurrencer Flash, en utilisant dotNET. Pour cela, ils ont développé un plug-in pour navigateurs (Internet-Explorer, Safari, et, avec quelques restrictions, Firefox). Ce plug-in, c'est SilverLight ; il permet d'utiliser XAML de façon dynamique (enfin, c'est ce qui est dit).
Jim Hugunin a travaillé sur SilverLight, et a permit de d'y utiliser ironPython (et Javascript). Normalement, tous les langages de dotNET devraient pouvoir l'utiliser.
Petit détail : les quelques exemples fournis fonctionnent aussi bien via le web que par chargement d'un fichier local.
Différences IronPython et CPython.
dotNET contient de nombreuses classe/méthodes, qui recouvrent de nombreux besoins, dans de nombreux secteurs. Et cela entre en concurrence directe avec la librairie standard de Python. IronPython a accès à toutes ces librairies. Dès lors, la question s'est posée, de choisir entre utiliser les possibilités de dotNET, et développer les adaptations nécessaires dans la librairie standard. La même question se pose aux utilisateurs d'ironPython, pour des fonctions qui existent à la fois dans dotNET et dans la librairie standard. Et, il n'y a pas de réponse universelle et simple, d'autant plus que, en passant par dotNET, IronPython a accès à toutes les librairies développées dans les autres langages (C#, J#, F#, VB.Net, C++.Net, Delphi.Net, etc.)
PythonNET
Il existe une autre voie : PythonNET. Là, on est du côté CPython (le Python normal, quoi), avec la possibilité d'appeler des éléments de dotNET. En gros, PythonNET utilise dotNET de l'extérieur, alors que IronPython travaille de l'intérieur.
Voilà un résumé de la situation.
@+
MCI
olive
Bonjour,
Alors là, merci Michel !
C'est vraiment sympa de prendre le temps de répondre avec autant de détail et de clareté.
Merci également à toi Eric.
Bonne journée et bon python à tous,
Olivier.
Bonjour,
Alors là, merci Michel !
C'est vraiment sympa de prendre le temps de répondre avec autant de
détail et de clareté.
