Python 2.5 est sorti.

Python 2.5 est sorti.
Et... c'est là : http://www.python.org/2.5

Bonne Nouvelle !

Cela dit, me trompe-je, ou le "RAD" avec python, sans se poser de question,
et avec la portabilité en prime, ce n'est pas pour cette version ?

Sauf erreur :

1/ Il n'y a pas de toolkit graphique intégré, sinon TkInter qui est tout de
même limité, pas pratique, moche et encore moche !

2/ Il n'y a pas non plus d'environnement de développement "moderne" (avec
intellisense, débuggeur intégré, et un designer pour l'interface graphique)
? Quelque chose comme #Develop (
http://www.icsharpcode.com/OpenSource/SD/Default.aspx )

Dommage, non ?

Fil wrote:

Python 2.5 est sorti.
Et... c'est là : http://www.python.org/2.5

Bonne Nouvelle !

Cela dit, me trompe-je, ou le "RAD" avec python, sans se poser de question,
et avec la portabilité en prime, ce n'est pas pour cette version ?

Si tu veux dire par là un outil RAD intégré à la bibliothèque standard,
je pense que ce n'est effectivement ni pour cette version, ni pour les
suivantes.

Sauf erreur :

1/ Il n'y a pas de toolkit graphique intégré, sinon TkInter qui est tout de
même limité, pas pratique, moche et encore moche !

Je n'aime pas spécialement Tk non plus, mais c'est probablement la
meilleure solution "minimale". En ce qui me concerne, le simple fait
d'avoir un GUI toolkit dans la biblio standard est déjà discutable...

2/ Il n'y a pas non plus d'environnement de développement "moderne" (avec
intellisense, débuggeur intégré, et un designer pour l'interface graphique)

A part quelques technos propriétaires et non portables (Delphi, VB etc)
où c'est le langage qui est intégré à l'IDE plus que l'inverse, aucun
langage n'intègre ce genre de choses dans sa bibliothèque standard. Tout
cela est trop dépendant du GUI toolkit choisi (ou imposé, selon les
projets) et donc en partie de la plateforme cible pour avoir sa place
dans le langage lui-même.

En ce qui concerne les "environnement de développement "moderne"",
personnellement,j'attend toujours d'en trouver aussi puissant et
versatile que Emacs. Accessoirement, je travaille avec une bonne
demi-douzaine de langages (Python, PHP, javascript, C, bash, (x|ht)ml,
css, SQL, LDAP etc), et avoir à utiliser autant d'IDE "modernes" que de
langage serait une horreur. Enfin, je n'écris plus de client lourd
depuis plusieurs années (ligne de commande ou web uniquement), donc je
n'ai absolument pas l'usage d'un GUI designer.

Dommage, non ?

Pas pour moi.

--
bruno desthuilliers
python -c "print '@'.join(['.'.join([w[::-1] for w in p.split('.')]) for
p in 'onurb@xiludom.gro'.split('@')])"

1/ Il n'y a pas de toolkit graphique intégré, sinon TkInter qui est tout de
même limité, pas pratique, moche et encore moche !
Je n'aime pas spécialement Tk non plus, mais c'est probablement la

meilleure solution "minimale". En ce qui me concerne, le simple fait
d'avoir un GUI toolkit dans la biblio standard est déjà discutable...

Le fait qu'il soit minimal est un bon point, quand meme.

En ce qui concerne les "environnement de développement "moderne"",
personnellement,j'attend toujours d'en trouver aussi puissant et
versatile que Emacs. Accessoirement, je travaille avec une bonne
demi-douzaine de langages (Python, PHP, javascript, C, bash, (x|ht)ml,
css, SQL, LDAP etc), et avoir à utiliser autant d'IDE "modernes" que de
langage serait une horreur.

Ca justifie le besoin d'avoir un portable dernier cri de chez Surcouf. :-)

Si tu veux dire par là un outil RAD intégré à la bibliothèque standard,
je pense que ce n'est effectivement ni pour cette version, ni pour les
suivantes.

Je ne comprends pas trop ce que "RAD intégré à la bibliotheque standard"
peut signifier ? En schématisant, sous l'étiquette "Python", on trouve un
langage et ses bibliothèques. Mon (gros) regret est de ne pas trouver "en
standard" autre chose que Tk pour l'interface graphique. Un autre gros
regret est de ne pas trouver mieux qu'IDLE comme environnement de
développement.

Je n'aime pas spécialement Tk non plus, mais c'est probablement la
meilleure solution "minimale".

Tk en meilleure solution minimale ? Il va être content Tk ;-) Mais si par
"minimale" il faut comprendre "fonctionnant sur autant d'OS majeurs que le
langage", alors il y a, me semble-t-il, beaucoup d'autres toolkit : GTK, QT,
wxWindows, et d'autres... Tous meilleurs que Tk, non ?

En ce qui me concerne, le simple fait
d'avoir un GUI toolkit dans la biblio standard est déjà discutable...

C'est le cas aujourd'hui avec Tkinter qui ne satisfait sans doute totalement
ni les tenants d'un toolkit dans la biblio standard, ni les autres... Autant
intégrer un meilleur toolkit dans la biblio, ce qui ne gènerait en rien ceux
qui ne font usage d'aucun toolkit tout en ne peinalisant pas ceux qui aurait
préféré n'importe quel autre (qu'il resterait possible d'exploiter comme
aujourd'hui)

A part quelques technos propriétaires et non portables (Delphi, VB etc)
où c'est le langage qui est intégré à l'IDE plus que l'inverse, aucun
langage n'intègre ce genre de choses dans sa bibliothèque standard.

A te lire, on pourrait croire que l'IDE intègre le langage qui intègre la
bibliothèque standard ?

AMHA, c'est plutôt l'inverse !

"langage qui est intégré à l'IDE plus que l'inverse" : que dire alors de
tous les EDI "non Microsoft" (Borland, SharpDevelop) dédié au Framework .Net
? Que dire alors aussi des EDI pour la plateforme Java ? Et un jour, pour
Mono ? J'en oublie ? Pour les cas cités, un EDI vise au moins un "Framework"
qui est exploité via un (ou plusieurs!) langage(s) et compilateur(s). Le
langage, et plus encore le Framework, existe totalement en dehors de tel ou
tel EDI. Pour preuve : tu peux utiliser un simple editeur (ou Emacs) pour
coder, et compiler "à la main" en faisant appel au complilateur via la
"ligne de commande".

"aucun langage n'intègre ce genre de choses dans sa bibliothèque standard" :
si tu penses au Framework .Net, à Java, à Mono, alors tu établis une toute
autre relation entre un langage et une "bibliotheque standard" : le langage
n'intègre pas "sa" bibliotheque standard ! Au contraire, ce n'est pas le
langage qui prime, mais la "bibliotheque" : un langage ne fait qu'exploiter
une "bibliothèque" (Framework) qui peut-être utilisées par plusieurs
langages.

En ce qui concerne les "environnement de développement "moderne"",
personnellement,j'attend toujours d'en trouver aussi puissant et
versatile que Emacs. Accessoirement, je travaille avec une bonne
demi-douzaine de langages (Python, PHP, javascript, C, bash, (x|ht)ml,
css, SQL, LDAP etc), et avoir à utiliser autant d'IDE "modernes" que de
langage serait une horreur. Enfin, je n'écris plus de client lourd
depuis plusieurs années (ligne de commande ou web uniquement), donc je
n'ai absolument pas l'usage d'un GUI designer.

Dommage, non ?

Pas pour moi.

Certes. Pas pour toi. Mais d'autres que toi réalisent des clients lourds. Et
aiment les EDI "à la Delphi" qui remportent un vif succès. Un bon EDI aide
grandement à rendre un langage populaire !

Certes. Pas pour toi. Mais d'autres que toi réalisent des clients lourds. Et
aiment les EDI "à la Delphi" qui remportent un vif succès. Un bon EDI aide
grandement à rendre un langage populaire !

Pour les clients lourds, FreePascal dans l'environnement Lazarus :

Libre et gratuit, clone (compatible) de Delphi/Kylix, developpement pour
Linux (i386+Sparc), FreeBSD, MacOSX and Win32.

http://www.lazarus.freepascal.org/


Liaison avec Python :

http://mmm-experts.com/Products.aspx?ProductId=3

Doc en Français :

http://guigui.developpez.com/Tutoriel/Delphi/PythonD7BDD/


Je n'ai pas encore testé l'intégration avec Python (je travaille
essentiellement en Prolog, en ce moment).

Cordialement

On 20-09-2006, Fil wrote:

Python 2.5 est sorti.
Et... c'est là : http://www.python.org/2.5

Bonne Nouvelle !

Cela dit, me trompe-je, ou le "RAD" avec python, sans se poser de question,
et avec la portabilité en prime, ce n'est pas pour cette version ?

Autant je vois l'intérêt d'un RAD avec des langages comme java qui sont
très pénibles à taper, autant avec un langage comme python je ne vois
pas du tout...

Sauf erreur :

1/ Il n'y a pas de toolkit graphique intégré, sinon TkInter qui est tout de
même limité, pas pratique, moche et encore moche !

2/ Il n'y a pas non plus d'environnement de développement "moderne" (avec
intellisense, débuggeur intégré, et un designer pour l'interface graphique)
? Quelque chose comme #Develop (
http://www.icsharpcode.com/OpenSource/SD/Default.aspx )

Même réponse que plus haut, un bon éditeur suffit... si "moderne"
signifi adapté à ce que l'on fait aujourd'hui, on à déjà largement ce
qu'il faut...

Dommage, non ?

non, ce qui serait dommage c'est que les développeurs du langage
s'occupent d'environnement graphique. On voit ce que ça donne quand
Guido donne ne serait-ce que son avis sur un framework web ;-)

--
William Dodé - http://flibuste.net

Fil wrote:

Si tu veux dire par là un outil RAD intégré à la bibliothèque standard,
je pense que ce n'est effectivement ni pour cette version, ni pour les
suivantes.

Je ne comprends pas trop ce que "RAD intégré à la bibliotheque standard"
peut signifier ?

Tkinter est un GUI Toolkit intégré à la bibliothèque standard. wxPython
est un GUI toolkit non intégré à la bibliothèque standard.

En schématisant, sous l'étiquette "Python", on trouve un
langage et ses bibliothèques.

un langage et sa bibliothèque *standard*, c'est à dire celle distribuée
avec le langage. wxPython n'est pas distribué avec Python, mais c'est
néamnoins une bibliothèque Python.

Mon (gros) regret est de ne pas trouver "en
standard" autre chose que Tk pour l'interface graphique. Un autre gros
regret est de ne pas trouver mieux qu'IDLE comme environnement de
développement.

Je n'aime pas spécialement Tk non plus, mais c'est probablement la
meilleure solution "minimale".

Tk en meilleure solution minimale ? Il va être content Tk ;-) Mais si par
"minimale" il faut comprendre "fonctionnant sur autant d'OS majeurs que le
langage", alors il y a, me semble-t-il, beaucoup d'autres toolkit : GTK, QT,
wxWindows, et d'autres... Tous meilleurs que Tk, non ?

PAQJS, GTK ne tourne pas sous MacOS, n'est pas simple à installer sous
Windows, et n'est pas nécessairement disponible sur tous les unices. La
situation n'est pas forcément très différente pour QT (minus les pb
d'installation sous Windows, mais plus les problèmes de licence) - et en
plus, c'est assez lourd. wxWidgets (ex wxWindows, merci MS) est le plus
portable du lot, mais si mon souvenir est bon, c'est un poids lourd
comparé à Tk.

Accessoirement, relire aussi ci-dessous:

En ce qui me concerne, le simple fait
d'avoir un GUI toolkit dans la biblio standard est déjà discutable...

C'est le cas aujourd'hui avec Tkinter qui ne satisfait sans doute totalement
ni les tenants d'un toolkit dans la biblio standard, ni les autres... Autant
intégrer un meilleur toolkit dans la biblio, ce qui ne gènerait en rien ceux
qui ne font usage d'aucun toolkit

Sauf si ça implique une biblio standard 2 fois plus grosse et des soucis
de compilation... Il y a par ailleurs de problèmes potentiels quant aux
agendas respectifs des développeurs de Python et de ceux des GUI
toolkits et de leur bindings Python qui peuvent par eux-même s'avérer
suffisant pour écarter cette éventualité.

tout en ne peinalisant pas ceux qui aurait
préféré n'importe quel autre (qu'il resterait possible d'exploiter comme
aujourd'hui)

Et alors ? Où est ton problème ? Puisque tu peux de toutes façons
installer ton toolkit préféré ?

A part quelques technos propriétaires et non portables (Delphi, VB etc)
où c'est le langage qui est intégré à l'IDE plus que l'inverse, aucun
langage n'intègre ce genre de choses dans sa bibliothèque standard.

A te lire, on pourrait croire que l'IDE intègre le langage qui intègre la
bibliothèque standard ?

Avec des technos comme Delphi/VB/Windew and co, c'est plus ou moins le
cas. Le packetage logiciel comprends l'IDE, le langage et ses biblios
(intégrant le GUI toolkit), et il est soit malaisé (et peu productif),
soit purement impossible de se passer de l'IDE - ne parlons même pas
d'utiliser un autre GUI Toolkit.

AMHA, c'est plutôt l'inverse !

"langage qui est intégré à l'IDE plus que l'inverse" : que dire alors de
tous les EDI "non Microsoft" (Borland, SharpDevelop) dédié au Framework .Net

Tous utilisent le même GUI Toolkit, qui fait partie des bibliothèques
standard du langage.

? Que dire alors aussi des EDI pour la plateforme Java ?

Idem.

Et un jour, pour
Mono ? J'en oublie ? Pour les cas cités, un EDI vise au moins un "Framework"
qui est exploité via un (ou plusieurs!) langage(s) et compilateur(s). Le
langage, et plus encore le Framework, existe totalement en dehors de tel ou
tel EDI. Pour preuve : tu peux utiliser un simple editeur (ou Emacs) pour
coder, et compiler "à la main" en faisant appel au complilateur via la
"ligne de commande".

"aucun langage n'intègre ce genre de choses dans sa bibliothèque standard" :

Effectivement, il y a Java comme contre-exemple. Bon, c'est aussi un
contre-exemple sur beaucoup d'autres points, hein...

si tu penses au Framework .Net, à Java, à Mono, alors tu établis une toute
autre relation entre un langage et une "bibliotheque standard" : le langage
n'intègre pas "sa" bibliotheque standard ! Au contraire, ce n'est pas le
langage qui prime, mais la "bibliotheque" : un langage ne fait qu'exploiter
une "bibliothèque" (Framework) qui peut-être utilisées par plusieurs
langages.

De même que wxWidget est utilisable depuis une tripotée de langages. Dis
voir, tu a quoi d'autre comme GUI Toolkit utilisable depuis (au hasard)
C# ? Et utilisable avec les IDE .Net, of course ?

En ce qui concerne les "environnement de développement "moderne"",
personnellement,j'attend toujours d'en trouver aussi puissant et
versatile que Emacs. Accessoirement, je travaille avec une bonne
demi-douzaine de langages (Python, PHP, javascript, C, bash, (x|ht)ml,
css, SQL, LDAP etc), et avoir à utiliser autant d'IDE "modernes" que de
langage serait une horreur. Enfin, je n'écris plus de client lourd
depuis plusieurs années (ligne de commande ou web uniquement), donc je
n'ai absolument pas l'usage d'un GUI designer.

Dommage, non ?
Pas pour moi.

Certes. Pas pour toi. Mais d'autres que toi réalisent des clients lourds.

Et ?

Et
aiment les EDI "à la Delphi"

Et ? Il y en a, non ? Je ne discute pas de l'intérêt (ou du manque
de...) de ces outils, mais de l'utilité de les intégrer à la
bibliothèque *standard* d'un langage généraliste et multiplateforme. Je
persiste à ne pas comprende ce qui te pose problème dans le fait d'avoir
le choix de tes outils ?

--
bruno desthuilliers
python -c "print '@'.join(['.'.join([w[::-1] for w in p.split('.')]) for
p in 'onurb@xiludom.gro'.split('@')])"

William Dode wrote:
(snip)

non, ce qui serait dommage c'est que les développeurs du langage
s'occupent d'environnement graphique. On voit ce que ça donne quand
Guido donne ne serait-ce que son avis sur un framework web ;-)

Lol !

Effectivement, et avec tout le respect dû à notre BDFL, il y a des fois
où j'aime autant qu'il s'abstienne...

--
bruno desthuilliers
python -c "print '@'.join(['.'.join([w[::-1] for w in p.split('.')]) for
p in 'onurb@xiludom.gro'.split('@')])"

Bruno Desthuilliers wrote:

William Dode wrote:
(snip)

non, ce qui serait dommage c'est que les développeurs du langage
s'occupent d'environnement graphique. On voit ce que ça donne quand
Guido donne ne serait-ce que son avis sur un framework web ;-)

Lol !

Effectivement, et avec tout le respect dû à notre BDFL, il y a des fois
où j'aime autant qu'il s'abstienne...

Quand Richard, Linus, ou Guido pettent un cable, il faut pardonner.

Bonsoir,

PAQJS, GTK ne tourne pas sous MacOS, n'est pas simple à installer sous
Windows, et n'est pas nécessairement disponible sur tous les unices. La
situation n'est pas forcément très différente pour QT (minus les pb
d'installation sous Windows, mais plus les problèmes de licence) - et en
plus, c'est assez lourd. wxWidgets (ex wxWindows, merci MS) est le plus
portable du lot, mais si mon souvenir est bon, c'est un poids lourd
comparé à Tk.
Tout à fait exact. Mais une fois qu'on le maîtrise, on peut vraiment

faire beaucoup de choses (voir la démo). Il y a un IDE très sympa
(AMHA). Il fonctionne avec py2exe. En bref, un truc tout à fait
impressionnant.
A+
jm