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 ?
Bah, quand je regarde nos élus de demain ... je me dis que je suis pas si mauvais ;-)
hg
luc
Bruno Desthuilliers wrote:
L'inverse de quoi ? (excuse moi, je ne suis pas sûr de comprendre dans quel sens il faut comprendre ta remarque).
De ça:
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.
En l'occurence:
"Par contre, il y a une très nette agressivité sur les groupes Python à l'égard de Ruby - généralement alliée à une totale méconnaissance du langage et à une mauvaise foi en béton armée."
C'est plus clair ?
-- Luc Heinrich
Bruno Desthuilliers <bdesth.quelquechose@free.quelquepart.fr> wrote:
L'inverse de quoi ? (excuse moi, je ne suis pas sûr de comprendre dans
quel sens il faut comprendre ta remarque).
De ça:
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.
En l'occurence:
"Par contre, il y a une très nette agressivité sur les groupes Python à
l'égard de Ruby - généralement alliée à une totale méconnaissance du
langage et à une mauvaise foi en béton armée."
L'inverse de quoi ? (excuse moi, je ne suis pas sûr de comprendre dans quel sens il faut comprendre ta remarque).
De ça:
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.
En l'occurence:
"Par contre, il y a une très nette agressivité sur les groupes Python à l'égard de Ruby - généralement alliée à une totale méconnaissance du langage et à une mauvaise foi en béton armée."
C'est plus clair ?
-- Luc Heinrich
Bruno Desthuilliers
Bruno Desthuilliers wrote:
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.
L'inverse est tout à fait vrai aussi.
L'inverse de quoi ? (excuse moi, je ne suis pas sûr de comprendre dans quel sens il faut comprendre ta remarque).
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.
Une vaste minorité, ce n'est plus une minorité. Si ? :)
Si.
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 concernce, je peux témoigner de la même chose au sujet de c.l.ruby. Dingue non ? :)
Non, pourquoi ? Au delà de ce qui les relie (et de ce qui les
différencie) d'un point de vue technique, les deux langages ont aussi en commun de susciter chez leurs utilisateurs un enthousiasme certain, et attirent AMHA le même genre de profils - en tous cas chez les développeurs un tant soit peu expérimentés (pas forcément en nombre d'années - plutôt en nombre de langages déjà utilisés !-).
Bruno Desthuilliers <bdesth.quelquechose@free.quelquepart.fr> wrote:
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.
L'inverse est tout à fait vrai aussi.
L'inverse de quoi ? (excuse moi, je ne suis pas sûr de comprendre dans
quel sens il faut comprendre ta remarque).
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.
Une vaste minorité, ce n'est plus une minorité. Si ? :)
Si.
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 concernce, je peux témoigner de la même chose au sujet de
c.l.ruby. Dingue non ? :)
Non, pourquoi ? Au delà de ce qui les relie (et de ce qui les
différencie) d'un point de vue technique, les deux langages ont aussi en
commun de susciter chez leurs utilisateurs un enthousiasme certain, et
attirent AMHA le même genre de profils - en tous cas chez les
développeurs un tant soit peu expérimentés (pas forcément en nombre
d'années - plutôt en nombre de langages déjà utilisés !-).
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.
L'inverse est tout à fait vrai aussi.
L'inverse de quoi ? (excuse moi, je ne suis pas sûr de comprendre dans quel sens il faut comprendre ta remarque).
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.
Une vaste minorité, ce n'est plus une minorité. Si ? :)
Si.
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 concernce, je peux témoigner de la même chose au sujet de c.l.ruby. Dingue non ? :)
Non, pourquoi ? Au delà de ce qui les relie (et de ce qui les
différencie) d'un point de vue technique, les deux langages ont aussi en commun de susciter chez leurs utilisateurs un enthousiasme certain, et attirent AMHA le même genre de profils - en tous cas chez les développeurs un tant soit peu expérimentés (pas forcément en nombre d'années - plutôt en nombre de langages déjà utilisés !-).
Bruno Desthuilliers
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.
C'est curieux, depuis que j'utilise Python (depuis la 1.5.2, je te laisse regarder quand elle est sortie), je n'ai eu ce problème qu'une fois, et encore tout récemment. Et pourtant, j'ai l'habitude de lire et souvent de reprendre du code écrit par d'autres...
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.
C'est curieux, depuis que j'utilise Python (depuis la 1.5.2, je te
laisse regarder quand elle est sortie), je n'ai eu ce problème qu'une
fois, et encore tout récemment. Et pourtant, j'ai l'habitude de lire et
souvent de reprendre du code écrit par d'autres...
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.
C'est curieux, depuis que j'utilise Python (depuis la 1.5.2, je te laisse regarder quand elle est sortie), je n'ai eu ce problème qu'une fois, et encore tout récemment. Et pourtant, j'ai l'habitude de lire et souvent de reprendre du code écrit par d'autres...
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.
En ce qui me concerne, tu peux ajouter le my, le $, et le ->
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.
Dans un bloc de code suffisament court, et avec un bon nommage, ce genre d'information n'apporte rien. Au contraire. D'une part, ces caractères non alphanumériques se lisent difficilement (en tous cas pour moi, et je pense pour la plupart des personnes appréciant une bonne littérature), et d'autre part ils limitent la généricité. En Python, certaines interfaces "implicites" (séquence - ou même simplement itérable -, tableau associatif, fichier, appelable, entre autres) sont très couramment implémentées par une grande quantité de classes différentes. Cela permet à du code écrit à l'époque de la 1.5.2 d'être encore utilisable avec des types qui ne pouvaient même pas exister à l'époque.
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.
J'allais répondre que ça pouvait aussi être un accès à un attribut, mais il me souvient maintenant (ou en tous cas il me semble me souvenir) que Ruby ne permet pas cela. Au temps pour moi...
D'ailleurs a ce propos, quitte a vouloir etre fool proof, Python aurait pu forcer l'encapsulation des donnees membres,
Attention : encapsulation != data hiding.
ca me parait plus fondamental que l'indentation.
Ah bon ? Et pourquoi donc ? (attention, y a un piège).
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,
Tu ne comprends pas bien Python, je vois, puisque tu insistes sur la dichotomie "données" vs "méthodes". En Python, tout est objet, et il n'y a donc pas de différence *fondamentale* entre "données membres" et méthodes - dans les deux cas, ce sont avant tout des attributs. Le fait que les seconds soient appelables ne change rien de ce point de vue.
mais c'est moins elegant je trouve.
A première vue, oui. Quand on comprend le modèle objet de Python - et entres autre le protocole Descripteur, qui est un des fondements dudit modèle, et qui sert *entre autres* à implémenter les méthodes et les propriétés, on se dit qu'entre ce petit peu d'élégance superficielle et les applications pratiques, le choix est vite fait.
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.
Oui.
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.
Là, je ne suis pas forcément d'accord. Encore une fois, il s'agit de bien comprendre le modèle objet de Python. Fonctions et classes sont deux exemples d'objets appelables (nb: un objet est appelable s'il lui-même a un attribut appelable nommé __call__). Partant de là, une "classe" est en fait à la fois un prototype et une usine. Bref, c'est un objet dont l'appel retourne un objet. Et comme tout est objet en Python, on a là un bel exemple du principe d'économie, lequel permet une grande généricité. Dans la logique objet, ce qui compte du point de vue du client, c'est l'interface, pas l'implémentation. Une application un poil intégriste de ce principe fait que certains développeurs Java vont t'expliquer qu'instancier directement une classe concrète dans le code client, c'est Mal(tm) - parce que ça couple trop le code client à une implémentation donnée. Morale, les dits développeurs créent systématiquement des usines[1] (le premier qui ajoute "à gaz" a gagné) - de même qu'ils créent systématiquement des accesseurs. En Python, point besoin ni de l'un ni de l'autre. Après tout, du point de vue du client, quelle importance si on instancie un bel objet tout neuf en appelant son contructeur ou si on appelle une fonction qui retourne un objet (déjà existant ou non) ? Du moment qu'on a l'objet qu'on voulait ?
[1] in english: factory
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.
Voir ma réponse à ta réponse à 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.
En ce qui me concerne, tu peux ajouter le my, le $, et le ->
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.
Dans un bloc de code suffisament court, et avec un bon nommage, ce genre
d'information n'apporte rien. Au contraire. D'une part, ces caractères
non alphanumériques se lisent difficilement (en tous cas pour moi, et je
pense pour la plupart des personnes appréciant une bonne littérature),
et d'autre part ils limitent la généricité. En Python, certaines
interfaces "implicites" (séquence - ou même simplement itérable -,
tableau associatif, fichier, appelable, entre autres) sont très
couramment implémentées par une grande quantité de classes différentes.
Cela permet à du code écrit à l'époque de la 1.5.2 d'être encore
utilisable avec des types qui ne pouvaient même pas exister à l'époque.
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.
J'allais répondre que ça pouvait aussi être un accès à un attribut, mais
il me souvient maintenant (ou en tous cas il me semble me souvenir) que
Ruby ne permet pas cela. Au temps pour moi...
D'ailleurs a ce propos, quitte a vouloir etre fool proof,
Python aurait pu forcer l'encapsulation des donnees membres,
Attention : encapsulation != data hiding.
ca me
parait plus fondamental que l'indentation.
Ah bon ? Et pourquoi donc ? (attention, y a un piège).
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,
Tu ne comprends pas bien Python, je vois, puisque tu insistes sur la
dichotomie "données" vs "méthodes". En Python, tout est objet, et il n'y
a donc pas de différence *fondamentale* entre "données membres" et
méthodes - dans les deux cas, ce sont avant tout des attributs. Le fait
que les seconds soient appelables ne change rien de ce point de vue.
mais c'est moins
elegant je trouve.
A première vue, oui. Quand on comprend le modèle objet de Python - et
entres autre le protocole Descripteur, qui est un des fondements dudit
modèle, et qui sert *entre autres* à implémenter les méthodes et les
propriétés, on se dit qu'entre ce petit peu d'élégance superficielle et
les applications pratiques, le choix est vite fait.
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.
Oui.
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.
Là, je ne suis pas forcément d'accord. Encore une fois, il s'agit de
bien comprendre le modèle objet de Python. Fonctions et classes sont
deux exemples d'objets appelables (nb: un objet est appelable s'il
lui-même a un attribut appelable nommé __call__). Partant de là, une
"classe" est en fait à la fois un prototype et une usine. Bref, c'est un
objet dont l'appel retourne un objet. Et comme tout est objet en Python,
on a là un bel exemple du principe d'économie, lequel permet une grande
généricité. Dans la logique objet, ce qui compte du point de vue du
client, c'est l'interface, pas l'implémentation. Une application un poil
intégriste de ce principe fait que certains développeurs Java vont
t'expliquer qu'instancier directement une classe concrète dans le code
client, c'est Mal(tm) - parce que ça couple trop le code client à une
implémentation donnée. Morale, les dits développeurs créent
systématiquement des usines[1] (le premier qui ajoute "à gaz" a gagné) -
de même qu'ils créent systématiquement des accesseurs. En Python, point
besoin ni de l'un ni de l'autre. Après tout, du point de vue du client,
quelle importance si on instancie un bel objet tout neuf en appelant son
contructeur ou si on appelle une fonction qui retourne un objet (déjà
existant ou non) ? Du moment qu'on a l'objet qu'on voulait ?
[1] in english: factory
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.
En ce qui me concerne, tu peux ajouter le my, le $, et le ->
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.
Dans un bloc de code suffisament court, et avec un bon nommage, ce genre d'information n'apporte rien. Au contraire. D'une part, ces caractères non alphanumériques se lisent difficilement (en tous cas pour moi, et je pense pour la plupart des personnes appréciant une bonne littérature), et d'autre part ils limitent la généricité. En Python, certaines interfaces "implicites" (séquence - ou même simplement itérable -, tableau associatif, fichier, appelable, entre autres) sont très couramment implémentées par une grande quantité de classes différentes. Cela permet à du code écrit à l'époque de la 1.5.2 d'être encore utilisable avec des types qui ne pouvaient même pas exister à l'époque.
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.
J'allais répondre que ça pouvait aussi être un accès à un attribut, mais il me souvient maintenant (ou en tous cas il me semble me souvenir) que Ruby ne permet pas cela. Au temps pour moi...
D'ailleurs a ce propos, quitte a vouloir etre fool proof, Python aurait pu forcer l'encapsulation des donnees membres,
Attention : encapsulation != data hiding.
ca me parait plus fondamental que l'indentation.
Ah bon ? Et pourquoi donc ? (attention, y a un piège).
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,
Tu ne comprends pas bien Python, je vois, puisque tu insistes sur la dichotomie "données" vs "méthodes". En Python, tout est objet, et il n'y a donc pas de différence *fondamentale* entre "données membres" et méthodes - dans les deux cas, ce sont avant tout des attributs. Le fait que les seconds soient appelables ne change rien de ce point de vue.
mais c'est moins elegant je trouve.
A première vue, oui. Quand on comprend le modèle objet de Python - et entres autre le protocole Descripteur, qui est un des fondements dudit modèle, et qui sert *entre autres* à implémenter les méthodes et les propriétés, on se dit qu'entre ce petit peu d'élégance superficielle et les applications pratiques, le choix est vite fait.
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.
Oui.
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.
Là, je ne suis pas forcément d'accord. Encore une fois, il s'agit de bien comprendre le modèle objet de Python. Fonctions et classes sont deux exemples d'objets appelables (nb: un objet est appelable s'il lui-même a un attribut appelable nommé __call__). Partant de là, une "classe" est en fait à la fois un prototype et une usine. Bref, c'est un objet dont l'appel retourne un objet. Et comme tout est objet en Python, on a là un bel exemple du principe d'économie, lequel permet une grande généricité. Dans la logique objet, ce qui compte du point de vue du client, c'est l'interface, pas l'implémentation. Une application un poil intégriste de ce principe fait que certains développeurs Java vont t'expliquer qu'instancier directement une classe concrète dans le code client, c'est Mal(tm) - parce que ça couple trop le code client à une implémentation donnée. Morale, les dits développeurs créent systématiquement des usines[1] (le premier qui ajoute "à gaz" a gagné) - de même qu'ils créent systématiquement des accesseurs. En Python, point besoin ni de l'un ni de l'autre. Après tout, du point de vue du client, quelle importance si on instancie un bel objet tout neuf en appelant son contructeur ou si on appelle une fonction qui retourne un objet (déjà existant ou non) ? Du moment qu'on a l'objet qu'on voulait ?
[1] in english: factory
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.
Voir ma réponse à ta réponse à Jean-Michel.
Bruno Desthuilliers
William Dode wrote:
Le seul cas où ça pose problème c'est quand on a un bloc à rallonge, hors même avec des balises de bloc, un code à rallonge c'est pas jojo, ça mérite juste d'être redécoupé.
Bien sur, mais le code a rallonge, Python ne l'empeche pas.
Non. Mais il ne l'encourage pas.
J'aurais prefere que l'interpreteur refuse les methodes de plus de 100 lignes (vous voyez je suis pas vache, je compte bien large). Ca ca aurait ete utile ! Quand vous avez a maintenir un code avec des methodes de 400 lignes, bizarrement les accolades vous manquent.
Une méthode de 400 lignes en Python ? Allo, Houston, nous avons un problème !-)
Alors j'en vois d'ici venir dire qu'aucun langage n'empeche de coder n'importe comment et que ce n'est pas la faute du langage.
Effectivement.
Certes, mais dans ce cas pourquoi essayer quand meme d'empecher ca avec l'identation forcee ?
Héritage historique. Dans la pratique, c'est effectivement discutable. Heureusement, Python a suffisament de qualités pour que ce point de détail (c'en est un dans la pratique - tu indentes toujours ton code proprement et régulièrement, non ?) reste à sa place : un point de détail.
On voit bien que ca ne marche pas,
Oui, après 17 ans, et un succès grandissant malgré l'absence de toute hype, il me semble évident que "ça ne marche pas".
ca ne sert qu'a ennuyer les honnetes gens qui doivent passer derriere pour reparer.
J'ai rarement pu travailler sur du code PHP sans devoir commencer par le réindenter, ajouter les accolades "manquantes" (ie: celles qui sont facultatives d'après la syntaxe mais que tout développeur sérieux mettra quand même), etc. Je n'ai eu qu'une fois dans ma vie - et très récemment - un problème de mélange de tab et d'espaces dans un code source Python.
William Dode wrote:
Le seul cas où ça pose problème c'est quand on a un bloc à rallonge,
hors même avec des balises de bloc, un code à rallonge c'est pas jojo,
ça mérite juste d'être redécoupé.
Bien sur, mais le code a rallonge, Python ne l'empeche pas.
Non. Mais il ne l'encourage pas.
J'aurais
prefere que l'interpreteur refuse les methodes de plus de 100 lignes
(vous voyez je suis pas vache, je compte bien large). Ca ca aurait ete
utile ! Quand vous avez a maintenir un code avec des methodes de 400
lignes, bizarrement les accolades vous manquent.
Une méthode de 400 lignes en Python ? Allo, Houston, nous avons un
problème !-)
Alors j'en vois d'ici venir dire qu'aucun langage n'empeche de coder
n'importe comment et que ce n'est pas la faute du langage.
Effectivement.
Certes, mais
dans ce cas pourquoi essayer quand meme d'empecher ca avec l'identation
forcee ?
Héritage historique. Dans la pratique, c'est effectivement discutable.
Heureusement, Python a suffisament de qualités pour que ce point de
détail (c'en est un dans la pratique - tu indentes toujours ton code
proprement et régulièrement, non ?) reste à sa place : un point de détail.
On voit bien que ca ne marche pas,
Oui, après 17 ans, et un succès grandissant malgré l'absence de toute
hype, il me semble évident que "ça ne marche pas".
ca ne sert qu'a ennuyer les
honnetes gens qui doivent passer derriere pour reparer.
J'ai rarement pu travailler sur du code PHP sans devoir commencer par le
réindenter, ajouter les accolades "manquantes" (ie: celles qui sont
facultatives d'après la syntaxe mais que tout développeur sérieux mettra
quand même), etc. Je n'ai eu qu'une fois dans ma vie - et très récemment
- un problème de mélange de tab et d'espaces dans un code source Python.
Le seul cas où ça pose problème c'est quand on a un bloc à rallonge, hors même avec des balises de bloc, un code à rallonge c'est pas jojo, ça mérite juste d'être redécoupé.
Bien sur, mais le code a rallonge, Python ne l'empeche pas.
Non. Mais il ne l'encourage pas.
J'aurais prefere que l'interpreteur refuse les methodes de plus de 100 lignes (vous voyez je suis pas vache, je compte bien large). Ca ca aurait ete utile ! Quand vous avez a maintenir un code avec des methodes de 400 lignes, bizarrement les accolades vous manquent.
Une méthode de 400 lignes en Python ? Allo, Houston, nous avons un problème !-)
Alors j'en vois d'ici venir dire qu'aucun langage n'empeche de coder n'importe comment et que ce n'est pas la faute du langage.
Effectivement.
Certes, mais dans ce cas pourquoi essayer quand meme d'empecher ca avec l'identation forcee ?
Héritage historique. Dans la pratique, c'est effectivement discutable. Heureusement, Python a suffisament de qualités pour que ce point de détail (c'en est un dans la pratique - tu indentes toujours ton code proprement et régulièrement, non ?) reste à sa place : un point de détail.
On voit bien que ca ne marche pas,
Oui, après 17 ans, et un succès grandissant malgré l'absence de toute hype, il me semble évident que "ça ne marche pas".
ca ne sert qu'a ennuyer les honnetes gens qui doivent passer derriere pour reparer.
J'ai rarement pu travailler sur du code PHP sans devoir commencer par le réindenter, ajouter les accolades "manquantes" (ie: celles qui sont facultatives d'après la syntaxe mais que tout développeur sérieux mettra quand même), etc. Je n'ai eu qu'une fois dans ma vie - et très récemment - un problème de mélange de tab et d'espaces dans un code source Python.
Bruno Desthuilliers
Bruno Desthuilliers wrote:
L'inverse de quoi ? (excuse moi, je ne suis pas sûr de comprendre dans quel sens il faut comprendre ta remarque).
De ça:
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.
En l'occurence:
"Par contre, il y a une très nette agressivité sur les groupes Python à l'égard de Ruby"
Ca doit être pour ça que quand la question "Python ou Ruby" est posée sur c.l.py, l'essentiel des réponses se résume à "essaye les deux et choisit celui qui te conviens le mieux".
" - généralement alliée à une totale méconnaissance du langage et à une mauvaise foi en béton armée."
Là encore, ce que je vois essentiellement relève plus soit de "je ne connais pas assez Ruby pour te dire" (méconnaissance, mais honnêteté), soit d'une réponse qui dénote d'une connaissance suffisante du langage.
C'est plus clair ?
Oui. Mais ça ne correspond en rien à ce que je vois depuis plusieurs années.
Bruno Desthuilliers <bdesth.quelquechose@free.quelquepart.fr> wrote:
L'inverse de quoi ? (excuse moi, je ne suis pas sûr de comprendre dans
quel sens il faut comprendre ta remarque).
De ça:
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.
En l'occurence:
"Par contre, il y a une très nette agressivité sur les groupes Python à
l'égard de Ruby"
Ca doit être pour ça que quand la question "Python ou Ruby" est posée
sur c.l.py, l'essentiel des réponses se résume à "essaye les deux et
choisit celui qui te conviens le mieux".
" - généralement alliée à une totale méconnaissance du
langage et à une mauvaise foi en béton armée."
Là encore, ce que je vois essentiellement relève plus soit de "je ne
connais pas assez Ruby pour te dire" (méconnaissance, mais honnêteté),
soit d'une réponse qui dénote d'une connaissance suffisante du langage.
C'est plus clair ?
Oui. Mais ça ne correspond en rien à ce que je vois depuis plusieurs années.
L'inverse de quoi ? (excuse moi, je ne suis pas sûr de comprendre dans quel sens il faut comprendre ta remarque).
De ça:
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.
En l'occurence:
"Par contre, il y a une très nette agressivité sur les groupes Python à l'égard de Ruby"
Ca doit être pour ça que quand la question "Python ou Ruby" est posée sur c.l.py, l'essentiel des réponses se résume à "essaye les deux et choisit celui qui te conviens le mieux".
" - généralement alliée à une totale méconnaissance du langage et à une mauvaise foi en béton armée."
Là encore, ce que je vois essentiellement relève plus soit de "je ne connais pas assez Ruby pour te dire" (méconnaissance, mais honnêteté), soit d'une réponse qui dénote d'une connaissance suffisante du langage.
C'est plus clair ?
Oui. Mais ça ne correspond en rien à ce que je vois depuis plusieurs années.
