truc a ecrire vite et mal a usage unique => perl
truc a ecrire vite et mal a usage unique => perl
truc a ecrire vite et mal a usage unique => perl
C'est vrai que la question initiale était "qui êtes vous et que faites
vous ?" et ça a dévié sur un débat, intéressant par ailleurs, entre python
et ruby.
Concernant le débat Python/Ruby, je ne poserais que quelques questions, ne
connaissant pas du tout ce langage (Ruby vous avez bien compris):
- existe-t-il des possibilités de développer des modules en C/C++ ?
- est-il multi plateformes ?
C'est vrai que la question initiale était "qui êtes vous et que faites
vous ?" et ça a dévié sur un débat, intéressant par ailleurs, entre python
et ruby.
Concernant le débat Python/Ruby, je ne poserais que quelques questions, ne
connaissant pas du tout ce langage (Ruby vous avez bien compris):
- existe-t-il des possibilités de développer des modules en C/C++ ?
- est-il multi plateformes ?
C'est vrai que la question initiale était "qui êtes vous et que faites
vous ?" et ça a dévié sur un débat, intéressant par ailleurs, entre python
et ruby.
Concernant le débat Python/Ruby, je ne poserais que quelques questions, ne
connaissant pas du tout ce langage (Ruby vous avez bien compris):
- existe-t-il des possibilités de développer des modules en C/C++ ?
- est-il multi plateformes ?
SoapPy, qui transforme naturellement des appels de fonction vers
XML-RPC;
wxPython qui permet de dériver en Python des objets C++;
py.test pour écrire des tests unitaires sans aucune librairie...
Une fois que cette couche est installée, l'interface devient tellement
naturelle qu'on l'oublie!
Un regret sur ce sujet: le langage SQL résiste à l'assimilation...
SoapPy, qui transforme naturellement des appels de fonction vers
XML-RPC;
wxPython qui permet de dériver en Python des objets C++;
py.test pour écrire des tests unitaires sans aucune librairie...
Une fois que cette couche est installée, l'interface devient tellement
naturelle qu'on l'oublie!
Un regret sur ce sujet: le langage SQL résiste à l'assimilation...
SoapPy, qui transforme naturellement des appels de fonction vers
XML-RPC;
wxPython qui permet de dériver en Python des objets C++;
py.test pour écrire des tests unitaires sans aucune librairie...
Une fois que cette couche est installée, l'interface devient tellement
naturelle qu'on l'oublie!
Un regret sur ce sujet: le langage SQL résiste à l'assimilation...
OK... aux erreurs d'indentation près.
OK... aux erreurs d'indentation près.
OK... aux erreurs d'indentation près.
Bruno Desthuilliers wrote:Désolé, j'ai essayé plusieurs fois d'apprendre Perl, je n'ai jama is pu
m'y faire. Idem en shell script et en PHP d'ailleurs.
Pour le PHP, je connais trop peu pour juger, mais ca pas l'air tres robus te,
tant au niveau du langage que de l'interpreteur.
Pour Perl, c'est dommage, c'est un chouette langage, m'enfin on s'en passe
tres bien quand on a Python.
Pour le shell tu dois quand meme bien etre capable d'en lire un peu non ? Ne
serait-ce que pour jeter un oeil aux scripts de demarrages de ton OS.
C'est pareil en Perl. Les %, @ et $ renseignent juste sur une interfac e,
tu implemente ce que tu veux en dessous ("perldoc perltie" pour en
savoir plus).
Au temps pour moi alors. Ceci étant, je trouve toujours (à titre
personnel et totalement subjectif of course) que ça relève plus de
brouillage que l'information.
Ok, si c'est Python qui le fait, c'est bien, c'est de la genericité, si
c'est Perl, c'est du brouillage d'information ;)
Oui : le protocole descripteur.
class Foo(object):
def __init__(self, bar):
self.bar = bar
@apply
def bar():
def fget(self):
return self._bar * 2
def fset(self, bar):
self._bar = bar
return property(**locals())
Argh! Mais que sont ces '@' et '**', ciel, des caracteres
non-alphanumeriques, mais c'est illisible !-)
Bon donc j'ai lu le 'How-To Guide for Descriptors' (une recherche en Goug le
Francais sur 'protocole descripteur' donne trois resultats qui sont des
articles Usenet d'un certain Bruno Desthuilliers),
c'etait assez stimulant
intellectuellement, je suis pas sur d'avoir tout bien compris, m'enfin
suffisament quand meme pour comprendre ton exemple. Enfin presque, je suis
aussi alle me renseigner sur locals() et me rafraichir la memoire sur
l'operateur **. Enfin, j'ai cherche en vain une reference sur @apply
, j'ai
pas trop insiste vu que je suis en mesure de comprendre la version sans
decorateurs
et que tu dis plus bas que c'est deprecié.
Donc voila, pfiou, tout ca pour ca. Et apres on va dire que Perl est obsc ur.
Au final, je pense que je vais garder ma solution a base de __getattr__,
nettement plus lisible, a mon tres subjectif avis.
Et avant que tu t'emballes, oui, j'ai bien compris que ca permettait pas que
de changer des attributs en valeurs calculées, mais que ca permet aussi de
faire des choses formidables comme des methodes statiques (whaou !)
et des
methodes de classes (dont je ne sais pas a quoi elle peuvent bien servir)
et plein d'autres choses ésoteriques dont sont friands les obfuscateurs
orientés objet pour rendre leur code incomprehensible au programmeur d' en
bas.
Par contre Perl n'est encore une fois pas en reste sur ce point, le nom
du constucteur est completement libre, j'ai choisi new() pour l'exempl e.
Du coup, pour peu que ta factory soit dans le meme package (ce qui ne
veut pas dire dans le meme fichier), elle peut remplacer un constructe ur
sans que le code client soit au courant.
Pas compris...
Bon, j'essaye par l'example alors.
# Creation d'une instance de Aldo et assignation a une variable $objet
my $objet = new Aldo;
# Definition de la classe Aldo
package Aldo;
sub new { return bless {}; }
Le jour ou je veux que new fasse autre que renvoyer une instance de Aldo,
comme par example renvoyer des instances d'autres classes, je modifie le
corps de new et je n'ai pas besoin de modifier le client.
# On modifie la definition de la classe Aldo
package Aldo;
sub new {
if (...) {
return new Bezu;
} else {
return new Sim;
}
}
Et voila :)
Bruno Desthuilliers wrote:
Désolé, j'ai essayé plusieurs fois d'apprendre Perl, je n'ai jama is pu
m'y faire. Idem en shell script et en PHP d'ailleurs.
Pour le PHP, je connais trop peu pour juger, mais ca pas l'air tres robus te,
tant au niveau du langage que de l'interpreteur.
Pour Perl, c'est dommage, c'est un chouette langage, m'enfin on s'en passe
tres bien quand on a Python.
Pour le shell tu dois quand meme bien etre capable d'en lire un peu non ? Ne
serait-ce que pour jeter un oeil aux scripts de demarrages de ton OS.
C'est pareil en Perl. Les %, @ et $ renseignent juste sur une interfac e,
tu implemente ce que tu veux en dessous ("perldoc perltie" pour en
savoir plus).
Au temps pour moi alors. Ceci étant, je trouve toujours (à titre
personnel et totalement subjectif of course) que ça relève plus de
brouillage que l'information.
Ok, si c'est Python qui le fait, c'est bien, c'est de la genericité, si
c'est Perl, c'est du brouillage d'information ;)
Oui : le protocole descripteur.
class Foo(object):
def __init__(self, bar):
self.bar = bar
@apply
def bar():
def fget(self):
return self._bar * 2
def fset(self, bar):
self._bar = bar
return property(**locals())
Argh! Mais que sont ces '@' et '**', ciel, des caracteres
non-alphanumeriques, mais c'est illisible !-)
Bon donc j'ai lu le 'How-To Guide for Descriptors' (une recherche en Goug le
Francais sur 'protocole descripteur' donne trois resultats qui sont des
articles Usenet d'un certain Bruno Desthuilliers),
c'etait assez stimulant
intellectuellement, je suis pas sur d'avoir tout bien compris, m'enfin
suffisament quand meme pour comprendre ton exemple. Enfin presque, je suis
aussi alle me renseigner sur locals() et me rafraichir la memoire sur
l'operateur **. Enfin, j'ai cherche en vain une reference sur @apply
, j'ai
pas trop insiste vu que je suis en mesure de comprendre la version sans
decorateurs
et que tu dis plus bas que c'est deprecié.
Donc voila, pfiou, tout ca pour ca. Et apres on va dire que Perl est obsc ur.
Au final, je pense que je vais garder ma solution a base de __getattr__,
nettement plus lisible, a mon tres subjectif avis.
Et avant que tu t'emballes, oui, j'ai bien compris que ca permettait pas que
de changer des attributs en valeurs calculées, mais que ca permet aussi de
faire des choses formidables comme des methodes statiques (whaou !)
et des
methodes de classes (dont je ne sais pas a quoi elle peuvent bien servir)
et plein d'autres choses ésoteriques dont sont friands les obfuscateurs
orientés objet pour rendre leur code incomprehensible au programmeur d' en
bas.
Par contre Perl n'est encore une fois pas en reste sur ce point, le nom
du constucteur est completement libre, j'ai choisi new() pour l'exempl e.
Du coup, pour peu que ta factory soit dans le meme package (ce qui ne
veut pas dire dans le meme fichier), elle peut remplacer un constructe ur
sans que le code client soit au courant.
Pas compris...
Bon, j'essaye par l'example alors.
# Creation d'une instance de Aldo et assignation a une variable $objet
my $objet = new Aldo;
# Definition de la classe Aldo
package Aldo;
sub new { return bless {}; }
Le jour ou je veux que new fasse autre que renvoyer une instance de Aldo,
comme par example renvoyer des instances d'autres classes, je modifie le
corps de new et je n'ai pas besoin de modifier le client.
# On modifie la definition de la classe Aldo
package Aldo;
sub new {
if (...) {
return new Bezu;
} else {
return new Sim;
}
}
Et voila :)
Bruno Desthuilliers wrote:Désolé, j'ai essayé plusieurs fois d'apprendre Perl, je n'ai jama is pu
m'y faire. Idem en shell script et en PHP d'ailleurs.
Pour le PHP, je connais trop peu pour juger, mais ca pas l'air tres robus te,
tant au niveau du langage que de l'interpreteur.
Pour Perl, c'est dommage, c'est un chouette langage, m'enfin on s'en passe
tres bien quand on a Python.
Pour le shell tu dois quand meme bien etre capable d'en lire un peu non ? Ne
serait-ce que pour jeter un oeil aux scripts de demarrages de ton OS.
C'est pareil en Perl. Les %, @ et $ renseignent juste sur une interfac e,
tu implemente ce que tu veux en dessous ("perldoc perltie" pour en
savoir plus).
Au temps pour moi alors. Ceci étant, je trouve toujours (à titre
personnel et totalement subjectif of course) que ça relève plus de
brouillage que l'information.
Ok, si c'est Python qui le fait, c'est bien, c'est de la genericité, si
c'est Perl, c'est du brouillage d'information ;)
Oui : le protocole descripteur.
class Foo(object):
def __init__(self, bar):
self.bar = bar
@apply
def bar():
def fget(self):
return self._bar * 2
def fset(self, bar):
self._bar = bar
return property(**locals())
Argh! Mais que sont ces '@' et '**', ciel, des caracteres
non-alphanumeriques, mais c'est illisible !-)
Bon donc j'ai lu le 'How-To Guide for Descriptors' (une recherche en Goug le
Francais sur 'protocole descripteur' donne trois resultats qui sont des
articles Usenet d'un certain Bruno Desthuilliers),
c'etait assez stimulant
intellectuellement, je suis pas sur d'avoir tout bien compris, m'enfin
suffisament quand meme pour comprendre ton exemple. Enfin presque, je suis
aussi alle me renseigner sur locals() et me rafraichir la memoire sur
l'operateur **. Enfin, j'ai cherche en vain une reference sur @apply
, j'ai
pas trop insiste vu que je suis en mesure de comprendre la version sans
decorateurs
et que tu dis plus bas que c'est deprecié.
Donc voila, pfiou, tout ca pour ca. Et apres on va dire que Perl est obsc ur.
Au final, je pense que je vais garder ma solution a base de __getattr__,
nettement plus lisible, a mon tres subjectif avis.
Et avant que tu t'emballes, oui, j'ai bien compris que ca permettait pas que
de changer des attributs en valeurs calculées, mais que ca permet aussi de
faire des choses formidables comme des methodes statiques (whaou !)
et des
methodes de classes (dont je ne sais pas a quoi elle peuvent bien servir)
et plein d'autres choses ésoteriques dont sont friands les obfuscateurs
orientés objet pour rendre leur code incomprehensible au programmeur d' en
bas.
Par contre Perl n'est encore une fois pas en reste sur ce point, le nom
du constucteur est completement libre, j'ai choisi new() pour l'exempl e.
Du coup, pour peu que ta factory soit dans le meme package (ce qui ne
veut pas dire dans le meme fichier), elle peut remplacer un constructe ur
sans que le code client soit au courant.
Pas compris...
Bon, j'essaye par l'example alors.
# Creation d'une instance de Aldo et assignation a une variable $objet
my $objet = new Aldo;
# Definition de la classe Aldo
package Aldo;
sub new { return bless {}; }
Le jour ou je veux que new fasse autre que renvoyer une instance de Aldo,
comme par example renvoyer des instances d'autres classes, je modifie le
corps de new et je n'ai pas besoin de modifier le client.
# On modifie la definition de la classe Aldo
package Aldo;
sub new {
if (...) {
return new Bezu;
} else {
return new Sim;
}
}
Et voila :)
Dans les deux cas, decorate() est un décorateur...
Dans les deux cas, decorate() est un décorateur...
Dans les deux cas, decorate() est un décorateur...
C'est pareil en Perl. Les %, @ et $ renseignent juste sur une
interface, tu implemente ce que tu veux en dessous ("perldoc perltie"
pour en savoir plus).
Au temps pour moi alors. Ceci étant, je trouve toujours (à titre
personnel et totalement subjectif of course) que ça relève plus de
brouillage que l'information.
Ok, si c'est Python qui le fait, c'est bien, c'est de la genericité, si
c'est Perl, c'est du brouillage d'information ;)
Pardon ? je ne comprends pas ce que tu veux dire, là ???
Bon donc j'ai lu le 'How-To Guide for Descriptors' (une recherche en
Gougle Francais sur 'protocole descripteur' donne trois resultats qui
sont des articles Usenet d'un certain Bruno Desthuilliers),
Qui c'est ?
@decorate
def some_func(): pass
n'est qu'un sucre syntaxique pour
def some_func(): pass
some_func = decorate(some_func)
Dans les deux cas, decorate() est un décorateur...
Donc voila, pfiou, tout ca pour ca. Et apres on va dire que Perl est
obscur.
Si tu trouve ça "obscur", va donc regarder les métaclasses !-)
Au final, je pense que je vais garder ma solution a base de __getattr__,
nettement plus lisible, a mon tres subjectif avis.
Dommage pour toi - et pour ceux qui devront maintenir ton code.
et plein d'autres choses ésoteriques dont sont friands les obfuscateurs
orientés objet pour rendre leur code incomprehensible au programmeur d'en
bas.
Tu ne comprends pas, donc tu dénigres, en somme ?
Dommage. Tous ces mécanismes permettent justement de rendre le code
client plus simple et lisible. Pour ce que ça vaut, Ruby propose
(d'une façon différente) des mécanismes très similaires, grâce
auxquels tout le monde s'extasie sur RoR. Les auteurs de RoR seraient-
ils donc des obfuscateurs orientés objet friands de choses ésotériques
destinées à rendre leur code incompréhensible au programmeur d'en
bas ?-)
Par contre Perl n'est encore une fois pas en reste sur ce point, le
nom du constucteur est completement libre, j'ai choisi new() pour
l'exemple. Du coup, pour peu que ta factory soit dans le meme package
(ce qui ne veut pas dire dans le meme fichier), elle peut remplacer un
constructeur sans que le code client soit au courant.
Pas compris...
Bon, j'essaye par l'example alors.
# Creation d'une instance de Aldo et assignation a une variable $objet
my $objet = new Aldo;
# Definition de la classe Aldo
package Aldo;
sub new { return bless {}; }
Le jour ou je veux que new fasse autre que renvoyer une instance de Aldo,
comme par example renvoyer des instances d'autres classes, je modifie le
corps de new et je n'ai pas besoin de modifier le client.
# foo.py
class Foo(object):
pass
class Bar(object):
def __new__(cls):
return Foo()
# client.py
import foo
t = foo.Bar()
Pas besoin de modifier le client non plus...
# On modifie la definition de la classe Aldo
package Aldo;
sub new {
if (...) {
return new Bezu;
} else {
return new Sim;
}
}
Et voila :)
Ok. C'est bien. Et si tu ne veux pas toucher au code de Aldo non plus,
tu fais comment ?-)
C'est pareil en Perl. Les %, @ et $ renseignent juste sur une
interface, tu implemente ce que tu veux en dessous ("perldoc perltie"
pour en savoir plus).
Au temps pour moi alors. Ceci étant, je trouve toujours (à titre
personnel et totalement subjectif of course) que ça relève plus de
brouillage que l'information.
Ok, si c'est Python qui le fait, c'est bien, c'est de la genericité, si
c'est Perl, c'est du brouillage d'information ;)
Pardon ? je ne comprends pas ce que tu veux dire, là ???
Bon donc j'ai lu le 'How-To Guide for Descriptors' (une recherche en
Gougle Francais sur 'protocole descripteur' donne trois resultats qui
sont des articles Usenet d'un certain Bruno Desthuilliers),
Qui c'est ?
@decorate
def some_func(): pass
n'est qu'un sucre syntaxique pour
def some_func(): pass
some_func = decorate(some_func)
Dans les deux cas, decorate() est un décorateur...
Donc voila, pfiou, tout ca pour ca. Et apres on va dire que Perl est
obscur.
Si tu trouve ça "obscur", va donc regarder les métaclasses !-)
Au final, je pense que je vais garder ma solution a base de __getattr__,
nettement plus lisible, a mon tres subjectif avis.
Dommage pour toi - et pour ceux qui devront maintenir ton code.
et plein d'autres choses ésoteriques dont sont friands les obfuscateurs
orientés objet pour rendre leur code incomprehensible au programmeur d'en
bas.
Tu ne comprends pas, donc tu dénigres, en somme ?
Dommage. Tous ces mécanismes permettent justement de rendre le code
client plus simple et lisible. Pour ce que ça vaut, Ruby propose
(d'une façon différente) des mécanismes très similaires, grâce
auxquels tout le monde s'extasie sur RoR. Les auteurs de RoR seraient-
ils donc des obfuscateurs orientés objet friands de choses ésotériques
destinées à rendre leur code incompréhensible au programmeur d'en
bas ?-)
Par contre Perl n'est encore une fois pas en reste sur ce point, le
nom du constucteur est completement libre, j'ai choisi new() pour
l'exemple. Du coup, pour peu que ta factory soit dans le meme package
(ce qui ne veut pas dire dans le meme fichier), elle peut remplacer un
constructeur sans que le code client soit au courant.
Pas compris...
Bon, j'essaye par l'example alors.
# Creation d'une instance de Aldo et assignation a une variable $objet
my $objet = new Aldo;
# Definition de la classe Aldo
package Aldo;
sub new { return bless {}; }
Le jour ou je veux que new fasse autre que renvoyer une instance de Aldo,
comme par example renvoyer des instances d'autres classes, je modifie le
corps de new et je n'ai pas besoin de modifier le client.
# foo.py
class Foo(object):
pass
class Bar(object):
def __new__(cls):
return Foo()
# client.py
import foo
t = foo.Bar()
Pas besoin de modifier le client non plus...
# On modifie la definition de la classe Aldo
package Aldo;
sub new {
if (...) {
return new Bezu;
} else {
return new Sim;
}
}
Et voila :)
Ok. C'est bien. Et si tu ne veux pas toucher au code de Aldo non plus,
tu fais comment ?-)
C'est pareil en Perl. Les %, @ et $ renseignent juste sur une
interface, tu implemente ce que tu veux en dessous ("perldoc perltie"
pour en savoir plus).
Au temps pour moi alors. Ceci étant, je trouve toujours (à titre
personnel et totalement subjectif of course) que ça relève plus de
brouillage que l'information.
Ok, si c'est Python qui le fait, c'est bien, c'est de la genericité, si
c'est Perl, c'est du brouillage d'information ;)
Pardon ? je ne comprends pas ce que tu veux dire, là ???
Bon donc j'ai lu le 'How-To Guide for Descriptors' (une recherche en
Gougle Francais sur 'protocole descripteur' donne trois resultats qui
sont des articles Usenet d'un certain Bruno Desthuilliers),
Qui c'est ?
@decorate
def some_func(): pass
n'est qu'un sucre syntaxique pour
def some_func(): pass
some_func = decorate(some_func)
Dans les deux cas, decorate() est un décorateur...
Donc voila, pfiou, tout ca pour ca. Et apres on va dire que Perl est
obscur.
Si tu trouve ça "obscur", va donc regarder les métaclasses !-)
Au final, je pense que je vais garder ma solution a base de __getattr__,
nettement plus lisible, a mon tres subjectif avis.
Dommage pour toi - et pour ceux qui devront maintenir ton code.
et plein d'autres choses ésoteriques dont sont friands les obfuscateurs
orientés objet pour rendre leur code incomprehensible au programmeur d'en
bas.
Tu ne comprends pas, donc tu dénigres, en somme ?
Dommage. Tous ces mécanismes permettent justement de rendre le code
client plus simple et lisible. Pour ce que ça vaut, Ruby propose
(d'une façon différente) des mécanismes très similaires, grâce
auxquels tout le monde s'extasie sur RoR. Les auteurs de RoR seraient-
ils donc des obfuscateurs orientés objet friands de choses ésotériques
destinées à rendre leur code incompréhensible au programmeur d'en
bas ?-)
Par contre Perl n'est encore une fois pas en reste sur ce point, le
nom du constucteur est completement libre, j'ai choisi new() pour
l'exemple. Du coup, pour peu que ta factory soit dans le meme package
(ce qui ne veut pas dire dans le meme fichier), elle peut remplacer un
constructeur sans que le code client soit au courant.
Pas compris...
Bon, j'essaye par l'example alors.
# Creation d'une instance de Aldo et assignation a une variable $objet
my $objet = new Aldo;
# Definition de la classe Aldo
package Aldo;
sub new { return bless {}; }
Le jour ou je veux que new fasse autre que renvoyer une instance de Aldo,
comme par example renvoyer des instances d'autres classes, je modifie le
corps de new et je n'ai pas besoin de modifier le client.
# foo.py
class Foo(object):
pass
class Bar(object):
def __new__(cls):
return Foo()
# client.py
import foo
t = foo.Bar()
Pas besoin de modifier le client non plus...
# On modifie la definition de la classe Aldo
package Aldo;
sub new {
if (...) {
return new Bezu;
} else {
return new Sim;
}
}
Et voila :)
Ok. C'est bien. Et si tu ne veux pas toucher au code de Aldo non plus,
tu fais comment ?-)
wrote:C'est pareil en Perl. Les %, @ et $ renseignent juste sur une
interface, tu implemente ce que tu veux en dessous ("perldoc perlti e"
pour en savoir plus).
Au temps pour moi alors. Ceci étant, je trouve toujours (à titre
personnel et totalement subjectif of course) que ça relève plus de
brouillage que l'information.
Ok, si c'est Python qui le fait, c'est bien, c'est de la genericité, si
c'est Perl, c'est du brouillage d'information ;)
Pardon ? je ne comprends pas ce que tu veux dire, là ???
Heu... je ne vois pas trop ce que tu comprends pas.
Bon donc j'ai lu le 'How-To Guide for Descriptors' (une recherche en
Gougle Francais sur 'protocole descripteur' donne trois resultats qui
sont des articles Usenet d'un certain Bruno Desthuilliers),
Qui c'est ?
Aucune idée, mais il a l'air de bien connaitre Python :)
Au final, je pense que je vais garder ma solution a base de __getattr_ _,
nettement plus lisible, a mon tres subjectif avis.
Dommage pour toi - et pour ceux qui devront maintenir ton code.
Pourquoi ? Quels sont les avantages de la solution utilisant le protocole
descripteur ?
Elle me parait beaucoup plus lourde,
moins lisible,
moins
facile à comprendre et à maintenir.
L'intervention de NicolasP est
d'ailleurs assez révélatrice.
et plein d'autres choses ésoteriques dont sont friands les obfuscate urs
orientés objet pour rendre leur code incomprehensible au programmeur d'en
bas.
Tu ne comprends pas, donc tu dénigres, en somme ?
Pas du tout, bien au contraire.
Dommage. Tous ces mécanismes permettent justement de rendre le code
client plus simple et lisible. Pour ce que ça vaut, Ruby propose
(d'une façon différente) des mécanismes très similaires, grâce
auxquels tout le monde s'extasie sur RoR. Les auteurs de RoR seraient-
ils donc des obfuscateurs orientés objet friands de choses ésotér iques
destinées à rendre leur code incompréhensible au programmeur d'en
bas ?-)
Ça m'étonnerait pas !-)
Arf, on tourne en rond :) Si tu dit que Python fait un truc et que je te dis
que Perl le fait aussi et que tu me redit que Python le fait aussi, ça peut
durer longtemps :)
bruno.desthuilli...@gmail.com wrote:
C'est pareil en Perl. Les %, @ et $ renseignent juste sur une
interface, tu implemente ce que tu veux en dessous ("perldoc perlti e"
pour en savoir plus).
Au temps pour moi alors. Ceci étant, je trouve toujours (à titre
personnel et totalement subjectif of course) que ça relève plus de
brouillage que l'information.
Ok, si c'est Python qui le fait, c'est bien, c'est de la genericité, si
c'est Perl, c'est du brouillage d'information ;)
Pardon ? je ne comprends pas ce que tu veux dire, là ???
Heu... je ne vois pas trop ce que tu comprends pas.
Bon donc j'ai lu le 'How-To Guide for Descriptors' (une recherche en
Gougle Francais sur 'protocole descripteur' donne trois resultats qui
sont des articles Usenet d'un certain Bruno Desthuilliers),
Qui c'est ?
Aucune idée, mais il a l'air de bien connaitre Python :)
Au final, je pense que je vais garder ma solution a base de __getattr_ _,
nettement plus lisible, a mon tres subjectif avis.
Dommage pour toi - et pour ceux qui devront maintenir ton code.
Pourquoi ? Quels sont les avantages de la solution utilisant le protocole
descripteur ?
Elle me parait beaucoup plus lourde,
moins lisible,
moins
facile à comprendre et à maintenir.
L'intervention de NicolasP est
d'ailleurs assez révélatrice.
et plein d'autres choses ésoteriques dont sont friands les obfuscate urs
orientés objet pour rendre leur code incomprehensible au programmeur d'en
bas.
Tu ne comprends pas, donc tu dénigres, en somme ?
Pas du tout, bien au contraire.
Dommage. Tous ces mécanismes permettent justement de rendre le code
client plus simple et lisible. Pour ce que ça vaut, Ruby propose
(d'une façon différente) des mécanismes très similaires, grâce
auxquels tout le monde s'extasie sur RoR. Les auteurs de RoR seraient-
ils donc des obfuscateurs orientés objet friands de choses ésotér iques
destinées à rendre leur code incompréhensible au programmeur d'en
bas ?-)
Ça m'étonnerait pas !-)
Arf, on tourne en rond :) Si tu dit que Python fait un truc et que je te dis
que Perl le fait aussi et que tu me redit que Python le fait aussi, ça peut
durer longtemps :)
wrote:C'est pareil en Perl. Les %, @ et $ renseignent juste sur une
interface, tu implemente ce que tu veux en dessous ("perldoc perlti e"
pour en savoir plus).
Au temps pour moi alors. Ceci étant, je trouve toujours (à titre
personnel et totalement subjectif of course) que ça relève plus de
brouillage que l'information.
Ok, si c'est Python qui le fait, c'est bien, c'est de la genericité, si
c'est Perl, c'est du brouillage d'information ;)
Pardon ? je ne comprends pas ce que tu veux dire, là ???
Heu... je ne vois pas trop ce que tu comprends pas.
Bon donc j'ai lu le 'How-To Guide for Descriptors' (une recherche en
Gougle Francais sur 'protocole descripteur' donne trois resultats qui
sont des articles Usenet d'un certain Bruno Desthuilliers),
Qui c'est ?
Aucune idée, mais il a l'air de bien connaitre Python :)
Au final, je pense que je vais garder ma solution a base de __getattr_ _,
nettement plus lisible, a mon tres subjectif avis.
Dommage pour toi - et pour ceux qui devront maintenir ton code.
Pourquoi ? Quels sont les avantages de la solution utilisant le protocole
descripteur ?
Elle me parait beaucoup plus lourde,
moins lisible,
moins
facile à comprendre et à maintenir.
L'intervention de NicolasP est
d'ailleurs assez révélatrice.
et plein d'autres choses ésoteriques dont sont friands les obfuscate urs
orientés objet pour rendre leur code incomprehensible au programmeur d'en
bas.
Tu ne comprends pas, donc tu dénigres, en somme ?
Pas du tout, bien au contraire.
Dommage. Tous ces mécanismes permettent justement de rendre le code
client plus simple et lisible. Pour ce que ça vaut, Ruby propose
(d'une façon différente) des mécanismes très similaires, grâce
auxquels tout le monde s'extasie sur RoR. Les auteurs de RoR seraient-
ils donc des obfuscateurs orientés objet friands de choses ésotér iques
destinées à rendre leur code incompréhensible au programmeur d'en
bas ?-)
Ça m'étonnerait pas !-)
Arf, on tourne en rond :) Si tu dit que Python fait un truc et que je te dis
que Perl le fait aussi et que tu me redit que Python le fait aussi, ça peut
durer longtemps :)
On 28 fév, 10:44, Alex Marandon wrote:wrote:Au final, je pense que je vais garder ma solution a base de
__getattr__,
nettement plus lisible, a mon tres subjectif avis.
Dommage pour toi - et pour ceux qui devront maintenir ton code.
Pourquoi ? Quels sont les avantages de la solution utilisant le protocole
descripteur ?
(nb : en l'occurence sous la forme de properties, ce qui n'est qu'une
des applications de ce protocole)
Un premier avantage est que la gestion des accès (get/set/del) est
regroupée par propriété, pas par type d'accès (on voit donc toutes les
'règles' d'une propriété en un même endroit). Un second avantage est
qu'il n'y a pas besoin de toucher __getattr__, __setattr__ etc à
chaque modif (donc moins de risque de casser autre chose au passage).
Un troisième avantage est qu'il est plus facile de remplacer une
property par un autre descripteur. Un quatrième avantage est que la
property (ou autre descripteur) apparait dans le listing des attributs
de l'objet (et peut avoir une docstring). Un cinquième avantage est
que ça évite de devoir modifier les règles de lookup par défaut si on
n'en a pas le besoin. Un sixième avantage est que ça permet de
modifier les règles de lookup si besoin est sans mélanger ça avec les
définitions des properties. Un septième avantage est que le
descripteur (property ou autre) étant un attribut de la classe, on
peut s'en servir dans la métaclasse (très pratique pour des mini (ou
pas mini) frameworks. En cherchant bien, je dois pouvoir en trouver
quelques autres encore...
On 28 fév, 10:44, Alex Marandon <a...@invalid.org> wrote:
bruno.desthuilli...@gmail.com wrote:
Au final, je pense que je vais garder ma solution a base de
__getattr__,
nettement plus lisible, a mon tres subjectif avis.
Dommage pour toi - et pour ceux qui devront maintenir ton code.
Pourquoi ? Quels sont les avantages de la solution utilisant le protocole
descripteur ?
(nb : en l'occurence sous la forme de properties, ce qui n'est qu'une
des applications de ce protocole)
Un premier avantage est que la gestion des accès (get/set/del) est
regroupée par propriété, pas par type d'accès (on voit donc toutes les
'règles' d'une propriété en un même endroit). Un second avantage est
qu'il n'y a pas besoin de toucher __getattr__, __setattr__ etc à
chaque modif (donc moins de risque de casser autre chose au passage).
Un troisième avantage est qu'il est plus facile de remplacer une
property par un autre descripteur. Un quatrième avantage est que la
property (ou autre descripteur) apparait dans le listing des attributs
de l'objet (et peut avoir une docstring). Un cinquième avantage est
que ça évite de devoir modifier les règles de lookup par défaut si on
n'en a pas le besoin. Un sixième avantage est que ça permet de
modifier les règles de lookup si besoin est sans mélanger ça avec les
définitions des properties. Un septième avantage est que le
descripteur (property ou autre) étant un attribut de la classe, on
peut s'en servir dans la métaclasse (très pratique pour des mini (ou
pas mini) frameworks. En cherchant bien, je dois pouvoir en trouver
quelques autres encore...
On 28 fév, 10:44, Alex Marandon wrote:wrote:Au final, je pense que je vais garder ma solution a base de
__getattr__,
nettement plus lisible, a mon tres subjectif avis.
Dommage pour toi - et pour ceux qui devront maintenir ton code.
Pourquoi ? Quels sont les avantages de la solution utilisant le protocole
descripteur ?
(nb : en l'occurence sous la forme de properties, ce qui n'est qu'une
des applications de ce protocole)
Un premier avantage est que la gestion des accès (get/set/del) est
regroupée par propriété, pas par type d'accès (on voit donc toutes les
'règles' d'une propriété en un même endroit). Un second avantage est
qu'il n'y a pas besoin de toucher __getattr__, __setattr__ etc à
chaque modif (donc moins de risque de casser autre chose au passage).
Un troisième avantage est qu'il est plus facile de remplacer une
property par un autre descripteur. Un quatrième avantage est que la
property (ou autre descripteur) apparait dans le listing des attributs
de l'objet (et peut avoir une docstring). Un cinquième avantage est
que ça évite de devoir modifier les règles de lookup par défaut si on
n'en a pas le besoin. Un sixième avantage est que ça permet de
modifier les règles de lookup si besoin est sans mélanger ça avec les
définitions des properties. Un septième avantage est que le
descripteur (property ou autre) étant un attribut de la classe, on
peut s'en servir dans la métaclasse (très pratique pour des mini (ou
pas mini) frameworks. En cherchant bien, je dois pouvoir en trouver
quelques autres encore...
On 28-02-2007, wrote:On 28 fév, 10:44, Alex Marandon wrote:wrote:Au final, je pense que je vais garder ma solution a base de
__getattr__,
nettement plus lisible, a mon tres subjectif avis.
Dommage pour toi - et pour ceux qui devront maintenir ton code.
Pourquoi ? Quels sont les avantages de la solution utilisant le protocole
descripteur ?
(nb : en l'occurence sous la forme de properties, ce qui n'est qu'une
des applications de ce protocole)
Un premier avantage est que la gestion des accès (get/set/del) est
regroupée par propriété, pas par type d'accès (on voit donc toutes les
'règles' d'une propriété en un même endroit). Un second avantage est
qu'il n'y a pas besoin de toucher __getattr__, __setattr__ etc à
chaque modif (donc moins de risque de casser autre chose au passage).
Un troisième avantage est qu'il est plus facile de remplacer une
property par un autre descripteur. Un quatrième avantage est que la
property (ou autre descripteur) apparait dans le listing des attributs
de l'objet (et peut avoir une docstring). Un cinquième avantage est
que ça évite de devoir modifier les règles de lookup par défaut si on
n'en a pas le besoin. Un sixième avantage est que ça permet de
modifier les règles de lookup si besoin est sans mélanger ça avec les
définitions des properties. Un septième avantage est que le
descripteur (property ou autre) étant un attribut de la classe, on
peut s'en servir dans la métaclasse (très pratique pour des mini (ou
pas mini) frameworks. En cherchant bien, je dois pouvoir en trouver
quelques autres encore...
C'est beaucoup plus rapide (en vitesse d'exécution).
On 28-02-2007, bruno.desthuilliers@gmail.com wrote:
On 28 fév, 10:44, Alex Marandon <a...@invalid.org> wrote:
bruno.desthuilli...@gmail.com wrote:
Au final, je pense que je vais garder ma solution a base de
__getattr__,
nettement plus lisible, a mon tres subjectif avis.
Dommage pour toi - et pour ceux qui devront maintenir ton code.
Pourquoi ? Quels sont les avantages de la solution utilisant le protocole
descripteur ?
(nb : en l'occurence sous la forme de properties, ce qui n'est qu'une
des applications de ce protocole)
Un premier avantage est que la gestion des accès (get/set/del) est
regroupée par propriété, pas par type d'accès (on voit donc toutes les
'règles' d'une propriété en un même endroit). Un second avantage est
qu'il n'y a pas besoin de toucher __getattr__, __setattr__ etc à
chaque modif (donc moins de risque de casser autre chose au passage).
Un troisième avantage est qu'il est plus facile de remplacer une
property par un autre descripteur. Un quatrième avantage est que la
property (ou autre descripteur) apparait dans le listing des attributs
de l'objet (et peut avoir une docstring). Un cinquième avantage est
que ça évite de devoir modifier les règles de lookup par défaut si on
n'en a pas le besoin. Un sixième avantage est que ça permet de
modifier les règles de lookup si besoin est sans mélanger ça avec les
définitions des properties. Un septième avantage est que le
descripteur (property ou autre) étant un attribut de la classe, on
peut s'en servir dans la métaclasse (très pratique pour des mini (ou
pas mini) frameworks. En cherchant bien, je dois pouvoir en trouver
quelques autres encore...
C'est beaucoup plus rapide (en vitesse d'exécution).
On 28-02-2007, wrote:On 28 fév, 10:44, Alex Marandon wrote:wrote:Au final, je pense que je vais garder ma solution a base de
__getattr__,
nettement plus lisible, a mon tres subjectif avis.
Dommage pour toi - et pour ceux qui devront maintenir ton code.
Pourquoi ? Quels sont les avantages de la solution utilisant le protocole
descripteur ?
(nb : en l'occurence sous la forme de properties, ce qui n'est qu'une
des applications de ce protocole)
Un premier avantage est que la gestion des accès (get/set/del) est
regroupée par propriété, pas par type d'accès (on voit donc toutes les
'règles' d'une propriété en un même endroit). Un second avantage est
qu'il n'y a pas besoin de toucher __getattr__, __setattr__ etc à
chaque modif (donc moins de risque de casser autre chose au passage).
Un troisième avantage est qu'il est plus facile de remplacer une
property par un autre descripteur. Un quatrième avantage est que la
property (ou autre descripteur) apparait dans le listing des attributs
de l'objet (et peut avoir une docstring). Un cinquième avantage est
que ça évite de devoir modifier les règles de lookup par défaut si on
n'en a pas le besoin. Un sixième avantage est que ça permet de
modifier les règles de lookup si besoin est sans mélanger ça avec les
définitions des properties. Un septième avantage est que le
descripteur (property ou autre) étant un attribut de la classe, on
peut s'en servir dans la métaclasse (très pratique pour des mini (ou
pas mini) frameworks. En cherchant bien, je dois pouvoir en trouver
quelques autres encore...
C'est beaucoup plus rapide (en vitesse d'exécution).
