Je me présente, utilisateur Windows et développeur occasionnel en VB
pour le boulot, principalement pour réaliser des interfaces utilisateur
avec des systèmes dacquisition de mesures physiques ou des commandes de
machines. Pourquoi VB ? Pour rester dans la continuité de ce qui avait
déjà été réalisé auparavant, tout simplement, le choix ne s'est jamais posé.
Actuellement, je cherche à évoluer dans un autre langage et à essayer
dintégrer de plus en plus Linux, que se soit pour une utilisation
personnelle ou professionnelle.
Renseignements pris, Python me semble être un langage en vogue et promis
à un bel avenir !
Je nai malheureusement pas trouvé (je nai peut être pas bien cherché)
beaucoup dexemples dapplications écrites en Python. Pouvez-vous men
citer ?
Jaurais également désiré connaître votre profil de programmeur ? Doù
venez-vous, pourquoi et pour quelles tâches utilisez-vous Pyhton ?
Utilisez-vous un environnement de développement tel que Boa ?
Du Python + XUL + javascript + intégration de librairies tiers pour réaliser une grosse [*] application pour tout ce qui est vidéo par Internet (et accessoirement en local).
Petite précision, Democracy n'utilise XUL que sous Windows. L'interface de la version Mac se base sur PyObjC/Cocoa et celle de la version Linux sur PyGtk.
Bravo aux développeurs. Ca gagne à être plus connu.
Merci ;)
-- Luc Heinrich
Laurent Pointal <laurent.pointal@limsi.fr> wrote:
Du Python + XUL + javascript + intégration de librairies tiers pour
réaliser une grosse [*] application pour tout ce qui est vidéo par
Internet (et accessoirement en local).
Petite précision, Democracy n'utilise XUL que sous Windows. L'interface
de la version Mac se base sur PyObjC/Cocoa et celle de la version Linux
sur PyGtk.
Bravo aux développeurs. Ca gagne à être plus connu.
Du Python + XUL + javascript + intégration de librairies tiers pour réaliser une grosse [*] application pour tout ce qui est vidéo par Internet (et accessoirement en local).
Petite précision, Democracy n'utilise XUL que sous Windows. L'interface de la version Mac se base sur PyObjC/Cocoa et celle de la version Linux sur PyGtk.
Bravo aux développeurs. Ca gagne à être plus connu.
Merci ;)
-- Luc Heinrich
hg
Bruno Desthuilliers wrote:
En ce qui me concerne, je peux témoigner que cl.py est un des ng où je vois le moins de RTFM et le plus de patience à l'égard des débutants (quelque soit leur niveau par ailleurs).
Alors je dit plus rien
Bruno Desthuilliers wrote:
En ce qui me concerne, je peux témoigner que cl.py est un des ng où je
vois le moins de RTFM et le plus de patience à l'égard des débutants
(quelque soit leur niveau par ailleurs).
En ce qui me concerne, je peux témoigner que cl.py est un des ng où je vois le moins de RTFM et le plus de patience à l'égard des débutants (quelque soit leur niveau par ailleurs).
Alors je dit plus rien
Eric Masson
(Luc Heinrich) writes:
'Lut,
Petite précision, Democracy n'utilise XUL que sous Windows.
Via une bibliothèque développée pour le projet ou alors disponible plus généralement ?
-- Ol: (enfin si, on peut toujours rêver, mais je suis prêt à parier une bouteille que la stratégie de Be ne bougera pas) BL: Ah si elle bouge : elle s'enfonce ;-) -+- BL in Guide du Macounet Pervers : Be, Inc - HOWTO Sink Different -+-
luc@honk-honk.com (Luc Heinrich) writes:
'Lut,
Petite précision, Democracy n'utilise XUL que sous Windows.
Via une bibliothèque développée pour le projet ou alors disponible plus
généralement ?
--
Ol: (enfin si, on peut toujours rêver, mais je suis prêt à parier une
bouteille que la stratégie de Be ne bougera pas)
BL: Ah si elle bouge : elle s'enfonce ;-)
-+- BL in Guide du Macounet Pervers : Be, Inc - HOWTO Sink Different -+-
Petite précision, Democracy n'utilise XUL que sous Windows.
Via une bibliothèque développée pour le projet ou alors disponible plus généralement ?
-- Ol: (enfin si, on peut toujours rêver, mais je suis prêt à parier une bouteille que la stratégie de Be ne bougera pas) BL: Ah si elle bouge : elle s'enfonce ;-) -+- BL in Guide du Macounet Pervers : Be, Inc - HOWTO Sink Different -+-
Bruno Desthuilliers
hg wrote:
Je pense qu'il faut aussi insiter sur le fait que les NG pythons (anglophone très actifs) sont _bien_ plus utiles que ceux de Ruby et Perl ... ou les gens on tendance à se grater le nombril et planter les nouveaux venus qui on l'outrecuidance de ne pas être des experts ... ou a expliquer pourquoi ils sont les meilleurs.
C'est marrant, c'est *exactement* ce qui se dit à propos des groupes Python dans les groupes Ruby. Dingue non ? :>
Oui, dingue, en effet. On voit régulièrement des discussions sur Ruby ou
Perl sur c.l.py, et à part quelques blagues sur le côté un poil cryptique de Perl, c'est généralement pour dire que globalement, le choix est essentiellement subjectif. Par contre, il y a une très nette agressivité sur les groupes Ruby à l'égard de Python - généralement alliée à une totale méconnaissance du langage et à une mauvaise foi en béton armée. Il ne s'agit bien sûr que d'une minorité de la communauté, mais une minorité assez vaste et active pour devenir une véritable nuisance.
En ce qui me concerne, je peux témoigner que cl.py est un des ng où je vois le moins de RTFM et le plus de patience à l'égard des débutants (quelque soit leur niveau par ailleurs).
hg <hg@nospam.org> wrote:
Je pense qu'il faut aussi insiter sur le fait que les NG pythons (anglophone
très actifs) sont _bien_ plus utiles que ceux de Ruby et Perl ... ou les
gens on tendance à se grater le nombril et planter les nouveaux venus qui
on l'outrecuidance de ne pas être des experts ... ou a expliquer pourquoi
ils sont les meilleurs.
C'est marrant, c'est *exactement* ce qui se dit à propos des groupes
Python dans les groupes Ruby. Dingue non ? :>
Oui, dingue, en effet. On voit régulièrement des discussions sur Ruby ou
Perl sur c.l.py, et à part quelques blagues sur le côté un poil
cryptique de Perl, c'est généralement pour dire que globalement, le
choix est essentiellement subjectif. Par contre, il y a une très nette
agressivité sur les groupes Ruby à l'égard de Python - généralement
alliée à une totale méconnaissance du langage et à une mauvaise foi en
béton armée. Il ne s'agit bien sûr que d'une minorité de la communauté,
mais une minorité assez vaste et active pour devenir une véritable nuisance.
En ce qui me concerne, je peux témoigner que cl.py est un des ng où je
vois le moins de RTFM et le plus de patience à l'égard des débutants
(quelque soit leur niveau par ailleurs).
Je pense qu'il faut aussi insiter sur le fait que les NG pythons (anglophone très actifs) sont _bien_ plus utiles que ceux de Ruby et Perl ... ou les gens on tendance à se grater le nombril et planter les nouveaux venus qui on l'outrecuidance de ne pas être des experts ... ou a expliquer pourquoi ils sont les meilleurs.
C'est marrant, c'est *exactement* ce qui se dit à propos des groupes Python dans les groupes Ruby. Dingue non ? :>
Oui, dingue, en effet. On voit régulièrement des discussions sur Ruby ou
Perl sur c.l.py, et à part quelques blagues sur le côté un poil cryptique de Perl, c'est généralement pour dire que globalement, le choix est essentiellement subjectif. Par contre, il y a une très nette agressivité sur les groupes Ruby à l'égard de Python - généralement alliée à une totale méconnaissance du langage et à une mauvaise foi en béton armée. Il ne s'agit bien sûr que d'une minorité de la communauté, mais une minorité assez vaste et active pour devenir une véritable nuisance.
En ce qui me concerne, je peux témoigner que cl.py est un des ng où je vois le moins de RTFM et le plus de patience à l'égard des débutants (quelque soit leur niveau par ailleurs).
luc
Eric Masson wrote:
Via une bibliothèque développée pour le projet ou alors disponible plus généralement ?
Via xulrunner.
<http://xulfr.org/wiki/XulRunner>
-- Luc Heinrich
Eric Masson <emss@free.fr> wrote:
Via une bibliothèque développée pour le projet ou alors disponible plus
généralement ?
Y'a pas le choix !!! quand je rentre en France, je vais lire les hyeroglyphes place de la concorde just pour me rappeler que j'aime pas PERL
Ok, et n'oublie pas d'effacer le module re de ta bibliotheque standard.
Je peux pas ...j'en ai besoin ... mais au débit de Perl, les expressions régulières existaient bien avant perl.
hg
Alex Marandon
jean-michel bain-cornu wrote:
jean-michel bain-cornu wrote:>
La structure d'un script python restera toujours lisible, quelle que soit la négligence du programmeur.
Si cette affirmation semble theoriquement tenir debout, la pratique montre que ce n'est pas malheureusement pas le cas, le programmeur negligent prendra en effet soin d'alterner entre espaces et tabulations et fera varier le nombre de ces espaces et tabulations au fil de son code.
Ce n'est pas un pb avec un éditeur qui tient la route ;-)
Ah ca, si il n'y a pas de solution, c'est qu'il n'y a pas de probleme. Or ta reponse montre bien qu'il y a un probleme. On a besoin d'un outil specifique pour palier a un defaut de conception du langage.
J'ai jusqu'ici pratique quotidiennement cinq langages de programmation (sans compter JS, XML, SQL, etc), toujours avec le meme editeur. Python est le seul avec lequel du code ecrit par d'autres devenait imparsable pour des raisons de formattage de texte, sans parler de la presentation du code. J'aurais donc du mal a croire que c'est mon editeur qui a des problemes. Par contre c'est vrai que ca ne m'est jamais arrive avec du code ecrit des le depart par mes soins.
jean-michel bain-cornu wrote:
jean-michel bain-cornu wrote:>
La structure d'un script python restera toujours lisible, quelle que
soit la négligence du programmeur.
Si cette affirmation semble theoriquement tenir debout, la pratique
montre que ce n'est pas malheureusement pas le cas, le programmeur
negligent prendra en effet soin d'alterner entre espaces et tabulations
et fera varier le nombre de ces espaces et tabulations au fil de son
code.
Ce n'est pas un pb avec un éditeur qui tient la route ;-)
Ah ca, si il n'y a pas de solution, c'est qu'il n'y a pas de probleme.
Or ta reponse montre bien qu'il y a un probleme. On a besoin d'un outil
specifique pour palier a un defaut de conception du langage.
J'ai jusqu'ici pratique quotidiennement cinq langages de programmation
(sans compter JS, XML, SQL, etc), toujours avec le meme editeur. Python
est le seul avec lequel du code ecrit par d'autres devenait imparsable
pour des raisons de formattage de texte, sans parler de la presentation
du code. J'aurais donc du mal a croire que c'est mon editeur qui a des
problemes. Par contre c'est vrai que ca ne m'est jamais arrive avec du
code ecrit des le depart par mes soins.
La structure d'un script python restera toujours lisible, quelle que soit la négligence du programmeur.
Si cette affirmation semble theoriquement tenir debout, la pratique montre que ce n'est pas malheureusement pas le cas, le programmeur negligent prendra en effet soin d'alterner entre espaces et tabulations et fera varier le nombre de ces espaces et tabulations au fil de son code.
Ce n'est pas un pb avec un éditeur qui tient la route ;-)
Ah ca, si il n'y a pas de solution, c'est qu'il n'y a pas de probleme. Or ta reponse montre bien qu'il y a un probleme. On a besoin d'un outil specifique pour palier a un defaut de conception du langage.
J'ai jusqu'ici pratique quotidiennement cinq langages de programmation (sans compter JS, XML, SQL, etc), toujours avec le meme editeur. Python est le seul avec lequel du code ecrit par d'autres devenait imparsable pour des raisons de formattage de texte, sans parler de la presentation du code. J'aurais donc du mal a croire que c'est mon editeur qui a des problemes. Par contre c'est vrai que ca ne m'est jamais arrive avec du code ecrit des le depart par mes soins.
Alex Marandon
hg wrote:
Y'a pas le choix !!! quand je rentre en France, je vais lire les hyeroglyphes place de la concorde just pour me rappeler que j'aime pas PERL
Ok, et n'oublie pas d'effacer le module re de ta bibliotheque standard.
hg wrote:
Y'a pas le choix !!! quand je rentre en France, je vais lire les
hyeroglyphes place de la concorde just pour me rappeler que j'aime pas PERL
Ok, et n'oublie pas d'effacer le module re de ta bibliotheque standard.
Y'a pas le choix !!! quand je rentre en France, je vais lire les hyeroglyphes place de la concorde just pour me rappeler que j'aime pas PERL
Ok, et n'oublie pas d'effacer le module re de ta bibliotheque standard.
Alex Marandon
Bruno Desthuilliers wrote:
Pas que ca, par exemple voici trois instructions equivalentes, laquelle est la plus lisible:
o = plop() # Python o = Plop.new # Ruby my $o = plop->new; # Perl
Pas la troisième en tous cas !-)
Si justement, la troisieme !-) Avec elle, on sait qu'on a affaire a un appel de methode et que cela nous sert a une initialiser une nouvelle variable. Seul le point virgule encombre pour rien, en fait. Je ne sais pas pourquoi beaucoup de gens sont effrayes par les caracteres rigolos de Perl, ils sont la pour nous aider. Quand on voit %toto on sait que c'est un tableau associatif, @toto c'est une liste, etc.
Donc, la première a au moins pour moi l'avantage d'être la plus explicite dans le sens où je vois bien l'appel de fonction - mais je reconnait que c'est subjectif.
Oui c'est subjectif puisque en Ruby, ca ne peut etre qu'un appel de methode. D'ailleurs a ce propos, quitte a vouloir etre fool proof, Python aurait pu forcer l'encapsulation des donnees membres, ca me parait plus fondamental que l'indentation. La solution Ruby est sur ce point super elegante. Apres c'est sur que en Python, on a vite fait de rediriger les access aux attributs vers des methodes, mais c'est moins elegant je trouve.
L'autre avantage de cette syntaxe, et là c'est moins subjectif, c'est le fait qu'on puisse, de façon transparente, remplacer la classe par n'importe quel objet appelable. Ca m'a déjà rendu service quand il a fallu remplacer une classe par une fonction "factory" dans un programme déjà conséquent.
Ah oui, bon point pour Python la. C'est vrai que la lisibilite s'oppose generalement a la genericite, plus on en dit sur ce qu'on fait, moins on se reserve de marge de manoeuvre pour faire ce qu'on veut en coulisse.
Pour l'indentation je reste convaincu que ca apporte plus de problemes que ca n'en evite,
Tu "reste convaincu" ? Par quoi ? Tu a réellement eu des problèmes avec ça ?
Oui, voir ma reponse a Jean-Michel.
Bruno Desthuilliers wrote:
Pas que ca, par exemple voici trois instructions equivalentes, laquelle
est la plus lisible:
o = plop() # Python
o = Plop.new # Ruby
my $o = plop->new; # Perl
Pas la troisième en tous cas !-)
Si justement, la troisieme !-) Avec elle, on sait qu'on a affaire a un
appel de methode et que cela nous sert a une initialiser une nouvelle
variable. Seul le point virgule encombre pour rien, en fait. Je ne sais
pas pourquoi beaucoup de gens sont effrayes par les caracteres rigolos
de Perl, ils sont la pour nous aider. Quand on voit %toto on sait que
c'est un tableau associatif, @toto c'est une liste, etc.
Donc, la première a au moins pour moi l'avantage d'être la plus
explicite dans le sens où je vois bien l'appel de fonction - mais je
reconnait que c'est subjectif.
Oui c'est subjectif puisque en Ruby, ca ne peut etre qu'un appel de
methode. D'ailleurs a ce propos, quitte a vouloir etre fool proof,
Python aurait pu forcer l'encapsulation des donnees membres, ca me
parait plus fondamental que l'indentation. La solution Ruby est sur ce
point super elegante. Apres c'est sur que en Python, on a vite fait de
rediriger les access aux attributs vers des methodes, mais c'est moins
elegant je trouve.
L'autre avantage de cette syntaxe, et là
c'est moins subjectif, c'est le fait qu'on puisse, de façon
transparente, remplacer la classe par n'importe quel objet appelable. Ca
m'a déjà rendu service quand il a fallu remplacer une classe par une
fonction "factory" dans un programme déjà conséquent.
Ah oui, bon point pour Python la. C'est vrai que la lisibilite s'oppose
generalement a la genericite, plus on en dit sur ce qu'on fait, moins on
se reserve de marge de manoeuvre pour faire ce qu'on veut en coulisse.
Pour
l'indentation je reste convaincu que ca apporte plus de problemes que ca
n'en evite,
Tu "reste convaincu" ? Par quoi ? Tu a réellement eu des problèmes avec
ça ?
Pas que ca, par exemple voici trois instructions equivalentes, laquelle est la plus lisible:
o = plop() # Python o = Plop.new # Ruby my $o = plop->new; # Perl
Pas la troisième en tous cas !-)
Si justement, la troisieme !-) Avec elle, on sait qu'on a affaire a un appel de methode et que cela nous sert a une initialiser une nouvelle variable. Seul le point virgule encombre pour rien, en fait. Je ne sais pas pourquoi beaucoup de gens sont effrayes par les caracteres rigolos de Perl, ils sont la pour nous aider. Quand on voit %toto on sait que c'est un tableau associatif, @toto c'est une liste, etc.
Donc, la première a au moins pour moi l'avantage d'être la plus explicite dans le sens où je vois bien l'appel de fonction - mais je reconnait que c'est subjectif.
Oui c'est subjectif puisque en Ruby, ca ne peut etre qu'un appel de methode. D'ailleurs a ce propos, quitte a vouloir etre fool proof, Python aurait pu forcer l'encapsulation des donnees membres, ca me parait plus fondamental que l'indentation. La solution Ruby est sur ce point super elegante. Apres c'est sur que en Python, on a vite fait de rediriger les access aux attributs vers des methodes, mais c'est moins elegant je trouve.
L'autre avantage de cette syntaxe, et là c'est moins subjectif, c'est le fait qu'on puisse, de façon transparente, remplacer la classe par n'importe quel objet appelable. Ca m'a déjà rendu service quand il a fallu remplacer une classe par une fonction "factory" dans un programme déjà conséquent.
Ah oui, bon point pour Python la. C'est vrai que la lisibilite s'oppose generalement a la genericite, plus on en dit sur ce qu'on fait, moins on se reserve de marge de manoeuvre pour faire ce qu'on veut en coulisse.
Pour l'indentation je reste convaincu que ca apporte plus de problemes que ca n'en evite,
Tu "reste convaincu" ? Par quoi ? Tu a réellement eu des problèmes avec ça ?
