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 ;-)
Tu n'aurais pas le texte, par hasard ?
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 ;-)
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 ;-)
Tu n'aurais pas le texte, par hasard ?
hg
jean-michel bain-cornu wrote:
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 ;-)
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 ;-)
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 ;-)
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 ;-)
Ce n'est pas à celui-là que je pensais mais à celui où il trouve que django serait ze one, dans un interview... De là ça a pas mal jasé dans les blogs, j'ai pas les liens...
amha, pour le web, c'est un peu différent des gui natives, on peut beaucoup plus facilement utiliser des briques éparses plutôt qu'un framework complet. Je vois plutôt quelques briques entrer dans la lib qu'un framework...
-- William Dodé - http://flibuste.net
On 20-09-2006, hg wrote:
jean-michel bain-cornu wrote:
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 ;-)
Ce n'est pas à celui-là que je pensais mais à celui où il trouve que
django serait ze one, dans un interview... De là ça a pas mal jasé dans
les blogs, j'ai pas les liens...
amha, pour le web, c'est un peu différent des gui natives, on peut
beaucoup plus facilement utiliser des briques éparses plutôt qu'un
framework complet. Je vois plutôt quelques briques entrer dans la lib
qu'un framework...
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 ;-)
Ce n'est pas à celui-là que je pensais mais à celui où il trouve que django serait ze one, dans un interview... De là ça a pas mal jasé dans les blogs, j'ai pas les liens...
amha, pour le web, c'est un peu différent des gui natives, on peut beaucoup plus facilement utiliser des briques éparses plutôt qu'un framework complet. Je vois plutôt quelques briques entrer dans la lib qu'un framework...
-- William Dodé - http://flibuste.net
Christophe Cavalaria
Fil wrote:
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 ?
J'aime pas wxWindows ( ça pue les MFC, les limitations à la con Win32 et c'est pas aussi portable qu'on pourrait l'esperer ), GTK marche vraiment mal sous Windows et PyQT est GPL ( et encore, c'est récent sous Windows ).
Si je devais choisir, je prendrais PyQT car la programation avec est très Pythonique ( bien plus que wx en tout cas ), même si c'est une couche très simple au dessus de QT C++ :) Preuve que ce dernier est bien fait.
Fil wrote:
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 ?
J'aime pas wxWindows ( ça pue les MFC, les limitations à la con Win32 et
c'est pas aussi portable qu'on pourrait l'esperer ), GTK marche vraiment
mal sous Windows et PyQT est GPL ( et encore, c'est récent sous Windows ).
Si je devais choisir, je prendrais PyQT car la programation avec est très
Pythonique ( bien plus que wx en tout cas ), même si c'est une couche très
simple au dessus de QT C++ :) Preuve que ce dernier est bien fait.
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 ?
J'aime pas wxWindows ( ça pue les MFC, les limitations à la con Win32 et c'est pas aussi portable qu'on pourrait l'esperer ), GTK marche vraiment mal sous Windows et PyQT est GPL ( et encore, c'est récent sous Windows ).
Si je devais choisir, je prendrais PyQT car la programation avec est très Pythonique ( bien plus que wx en tout cas ), même si c'est une couche très simple au dessus de QT C++ :) Preuve que ce dernier est bien fait.
hg
Christophe Cavalaria wrote:
Fil wrote:
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 ?
J'aime pas wxWindows ( ça pue les MFC, les limitations à la con Win32 et c'est pas aussi portable qu'on pourrait l'esperer ), GTK marche vraiment mal sous Windows et PyQT est GPL ( et encore, c'est récent sous Windows ).
Si je devais choisir, je prendrais PyQT car la programation avec est très Pythonique ( bien plus que wx en tout cas ), même si c'est une couche très simple au dessus de QT C++ :) Preuve que ce dernier est bien fait.
Pas d'accord ... même si j'ai rien contre les mfc, wxpython est fantastique, très portable ... _et_ gratuit sur Windows, ce qui n'est pas le cas de QT.
Christophe Cavalaria wrote:
Fil wrote:
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 ?
J'aime pas wxWindows ( ça pue les MFC, les limitations à la con Win32 et
c'est pas aussi portable qu'on pourrait l'esperer ), GTK marche vraiment
mal sous Windows et PyQT est GPL ( et encore, c'est récent sous Windows ).
Si je devais choisir, je prendrais PyQT car la programation avec est très
Pythonique ( bien plus que wx en tout cas ), même si c'est une couche très
simple au dessus de QT C++ :) Preuve que ce dernier est bien fait.
Pas d'accord ... même si j'ai rien contre les mfc, wxpython est
fantastique, très portable ... _et_ gratuit sur Windows, ce qui n'est
pas le cas de QT.
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 ?
J'aime pas wxWindows ( ça pue les MFC, les limitations à la con Win32 et c'est pas aussi portable qu'on pourrait l'esperer ), GTK marche vraiment mal sous Windows et PyQT est GPL ( et encore, c'est récent sous Windows ).
Si je devais choisir, je prendrais PyQT car la programation avec est très Pythonique ( bien plus que wx en tout cas ), même si c'est une couche très simple au dessus de QT C++ :) Preuve que ce dernier est bien fait.
Pas d'accord ... même si j'ai rien contre les mfc, wxpython est fantastique, très portable ... _et_ gratuit sur Windows, ce qui n'est pas le cas de QT.
Thomas Samson
hg writes:
Christophe Cavalaria wrote:
Fil wrote:
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 ?
J'aime pas wxWindows ( ça pue les MFC, les limitations à la con Win32 et c'est pas aussi portable qu'on pourrait l'esperer ), GTK marche vraiment mal sous Windows et PyQT est GPL ( et encore, c'est récent sous Windows ).
Si je devais choisir, je prendrais PyQT car la programation avec est très Pythonique ( bien plus que wx en tout cas ), même si c'est une couche très simple au dessus de QT C++ :) Preuve que ce dernier est bien fait.
Pas d'accord ... même si j'ai rien contre les mfc, wxpython est fantastique, très portable ... _et_ gratuit sur Windows, ce qui n'est pas le cas de QT.
Il faut se mettre a jour :) QT4 a une politique de double license pour toutes les plates-formes (windows, unix/x11, mac os X). PyQT suit la meme politique.
Par contre, qt fait 'un peu plus' que juste toolkit graphique. (bon, les autres aussi, dans des styles differents ...)
-- Thomas Samson * LG loves czech girls. <vincent> LG: do they have additional interesting "features" other girls don't have? ;) -- #Debian
hg <hg@nospam.com> writes:
Christophe Cavalaria wrote:
Fil wrote:
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 ?
J'aime pas wxWindows ( ça pue les MFC, les limitations à la con Win32 et
c'est pas aussi portable qu'on pourrait l'esperer ), GTK marche vraiment
mal sous Windows et PyQT est GPL ( et encore, c'est récent sous Windows ).
Si je devais choisir, je prendrais PyQT car la programation avec est très
Pythonique ( bien plus que wx en tout cas ), même si c'est une couche très
simple au dessus de QT C++ :) Preuve que ce dernier est bien fait.
Pas d'accord ... même si j'ai rien contre les mfc, wxpython est
fantastique, très portable ... _et_ gratuit sur Windows, ce qui n'est
pas le cas de QT.
Il faut se mettre a jour :)
QT4 a une politique de double license pour toutes les plates-formes
(windows, unix/x11, mac os X). PyQT suit la meme politique.
Par contre, qt fait 'un peu plus' que juste toolkit graphique.
(bon, les autres aussi, dans des styles differents ...)
--
Thomas Samson
* LG loves czech girls.
<vincent> LG: do they have additional interesting "features" other girls
don't have? ;)
-- #Debian
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 ?
J'aime pas wxWindows ( ça pue les MFC, les limitations à la con Win32 et c'est pas aussi portable qu'on pourrait l'esperer ), GTK marche vraiment mal sous Windows et PyQT est GPL ( et encore, c'est récent sous Windows ).
Si je devais choisir, je prendrais PyQT car la programation avec est très Pythonique ( bien plus que wx en tout cas ), même si c'est une couche très simple au dessus de QT C++ :) Preuve que ce dernier est bien fait.
Pas d'accord ... même si j'ai rien contre les mfc, wxpython est fantastique, très portable ... _et_ gratuit sur Windows, ce qui n'est pas le cas de QT.
Il faut se mettre a jour :) QT4 a une politique de double license pour toutes les plates-formes (windows, unix/x11, mac os X). PyQT suit la meme politique.
Par contre, qt fait 'un peu plus' que juste toolkit graphique. (bon, les autres aussi, dans des styles differents ...)
-- Thomas Samson * LG loves czech girls. <vincent> LG: do they have additional interesting "features" other girls don't have? ;) -- #Debian
jean-michel bain-cornu
Bonjour,
amha, pour le web, c'est un peu différent des gui natives, on peut beaucoup plus facilement utiliser des briques éparses plutôt qu'un framework complet. Je vois plutôt quelques briques entrer dans la lib qu'un framework...
Un peu comme ce qu'ils ont essayé de faire avec PHP-Pear. Ne serait-ce
qu'un petit gestionnaire de templates, ce serait pas mal.
Bonjour,
amha, pour le web, c'est un peu différent des gui natives, on peut
beaucoup plus facilement utiliser des briques éparses plutôt qu'un
framework complet. Je vois plutôt quelques briques entrer dans la lib
qu'un framework...
Un peu comme ce qu'ils ont essayé de faire avec PHP-Pear. Ne serait-ce
qu'un petit gestionnaire de templates, ce serait pas mal.
amha, pour le web, c'est un peu différent des gui natives, on peut beaucoup plus facilement utiliser des briques éparses plutôt qu'un framework complet. Je vois plutôt quelques briques entrer dans la lib qu'un framework...
Un peu comme ce qu'ils ont essayé de faire avec PHP-Pear. Ne serait-ce
qu'un petit gestionnaire de templates, ce serait pas mal.
hg
Thomas Samson wrote:
hg writes:
Christophe Cavalaria wrote:
Fil wrote:
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 ? J'aime pas wxWindows ( ça pue les MFC, les limitations à la con Win32 et
c'est pas aussi portable qu'on pourrait l'esperer ), GTK marche vraiment mal sous Windows et PyQT est GPL ( et encore, c'est récent sous Windows ).
Si je devais choisir, je prendrais PyQT car la programation avec est très Pythonique ( bien plus que wx en tout cas ), même si c'est une couche très simple au dessus de QT C++ :) Preuve que ce dernier est bien fait. Pas d'accord ... même si j'ai rien contre les mfc, wxpython est
fantastique, très portable ... _et_ gratuit sur Windows, ce qui n'est pas le cas de QT.
Il faut se mettre a jour :) QT4 a une politique de double license pour toutes les plates-formes (windows, unix/x11, mac os X). PyQT suit la meme politique.
Par contre, qt fait 'un peu plus' que juste toolkit graphique. (bon, les autres aussi, dans des styles differents ...)
1) Cette politique est _très_ jeune 2) wxWidget est "free" point-barre, pas de "truc-caché"
Thomas Samson wrote:
hg <hg@nospam.com> writes:
Christophe Cavalaria wrote:
Fil wrote:
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 ?
J'aime pas wxWindows ( ça pue les MFC, les limitations à la con Win32 et
c'est pas aussi portable qu'on pourrait l'esperer ), GTK marche vraiment
mal sous Windows et PyQT est GPL ( et encore, c'est récent sous Windows ).
Si je devais choisir, je prendrais PyQT car la programation avec est très
Pythonique ( bien plus que wx en tout cas ), même si c'est une couche très
simple au dessus de QT C++ :) Preuve que ce dernier est bien fait.
Pas d'accord ... même si j'ai rien contre les mfc, wxpython est
fantastique, très portable ... _et_ gratuit sur Windows, ce qui n'est
pas le cas de QT.
Il faut se mettre a jour :)
QT4 a une politique de double license pour toutes les plates-formes
(windows, unix/x11, mac os X). PyQT suit la meme politique.
Par contre, qt fait 'un peu plus' que juste toolkit graphique.
(bon, les autres aussi, dans des styles differents ...)
1) Cette politique est _très_ jeune 2) wxWidget est "free" point-barre,
pas de "truc-caché"
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 ? J'aime pas wxWindows ( ça pue les MFC, les limitations à la con Win32 et
c'est pas aussi portable qu'on pourrait l'esperer ), GTK marche vraiment mal sous Windows et PyQT est GPL ( et encore, c'est récent sous Windows ).
Si je devais choisir, je prendrais PyQT car la programation avec est très Pythonique ( bien plus que wx en tout cas ), même si c'est une couche très simple au dessus de QT C++ :) Preuve que ce dernier est bien fait. Pas d'accord ... même si j'ai rien contre les mfc, wxpython est
fantastique, très portable ... _et_ gratuit sur Windows, ce qui n'est pas le cas de QT.
Il faut se mettre a jour :) QT4 a une politique de double license pour toutes les plates-formes (windows, unix/x11, mac os X). PyQT suit la meme politique.
Par contre, qt fait 'un peu plus' que juste toolkit graphique. (bon, les autres aussi, dans des styles differents ...)
1) Cette politique est _très_ jeune 2) wxWidget est "free" point-barre, pas de "truc-caché"
Bruno Desthuilliers
jean-michel bain-cornu wrote:
Bonjour,
amha, pour le web, c'est un peu différent des gui natives, on peut beaucoup plus facilement utiliser des briques éparses plutôt qu'un framework complet. Je vois plutôt quelques briques entrer dans la lib qu'un framework...
Un peu comme ce qu'ils ont essayé de faire avec PHP-Pear.
Je peux vomir ?
Ne serait-ce qu'un petit gestionnaire de templates, ce serait pas mal.
Oui mais lequel ?-)
-- bruno desthuilliers python -c "print '@'.join(['.'.join([w[::-1] for w in p.split('.')]) for p in ''.split('@')])"
jean-michel bain-cornu wrote:
Bonjour,
amha, pour le web, c'est un peu différent des gui natives, on peut
beaucoup plus facilement utiliser des briques éparses plutôt qu'un
framework complet. Je vois plutôt quelques briques entrer dans la lib
qu'un framework...
Un peu comme ce qu'ils ont essayé de faire avec PHP-Pear.
Je peux vomir ?
Ne serait-ce
qu'un petit gestionnaire de templates, ce serait pas mal.
Oui mais lequel ?-)
--
bruno desthuilliers
python -c "print '@'.join(['.'.join([w[::-1] for w in p.split('.')]) for
p in 'onurb@xiludom.gro'.split('@')])"
amha, pour le web, c'est un peu différent des gui natives, on peut beaucoup plus facilement utiliser des briques éparses plutôt qu'un framework complet. Je vois plutôt quelques briques entrer dans la lib qu'un framework...
Un peu comme ce qu'ils ont essayé de faire avec PHP-Pear.
Je peux vomir ?
Ne serait-ce qu'un petit gestionnaire de templates, ce serait pas mal.
Oui mais lequel ?-)
-- bruno desthuilliers python -c "print '@'.join(['.'.join([w[::-1] for w in p.split('.')]) for p in ''.split('@')])"
William Dode
On 21-09-2006, Bruno Desthuilliers wrote:
jean-michel bain-cornu wrote:
Bonjour,
amha, pour le web, c'est un peu différent des gui natives, on peut beaucoup plus facilement utiliser des briques éparses plutôt qu'un framework complet. Je vois plutôt quelques briques entrer dans la lib qu'un framework...
Un peu comme ce qu'ils ont essayé de faire avec PHP-Pear.
Je peux vomir ?
Après toi
Ne serait-ce qu'un petit gestionnaire de templates, ce serait pas mal.
Templates provide simpler string substitutions as described in PEP 292. Instead of the normal "%"-based substitutions, Templates support "$"-based substitutions...
-- William Dodé - http://flibuste.net
On 21-09-2006, Bruno Desthuilliers wrote:
jean-michel bain-cornu wrote:
Bonjour,
amha, pour le web, c'est un peu différent des gui natives, on peut
beaucoup plus facilement utiliser des briques éparses plutôt qu'un
framework complet. Je vois plutôt quelques briques entrer dans la lib
qu'un framework...
Un peu comme ce qu'ils ont essayé de faire avec PHP-Pear.
Je peux vomir ?
Après toi
Ne serait-ce
qu'un petit gestionnaire de templates, ce serait pas mal.
Templates provide simpler string substitutions as described in PEP 292.
Instead of the normal "%"-based substitutions, Templates support
"$"-based substitutions...
amha, pour le web, c'est un peu différent des gui natives, on peut beaucoup plus facilement utiliser des briques éparses plutôt qu'un framework complet. Je vois plutôt quelques briques entrer dans la lib qu'un framework...
Un peu comme ce qu'ils ont essayé de faire avec PHP-Pear.
Je peux vomir ?
Après toi
Ne serait-ce qu'un petit gestionnaire de templates, ce serait pas mal.
Templates provide simpler string substitutions as described in PEP 292. Instead of the normal "%"-based substitutions, Templates support "$"-based substitutions...
