Michel Claveau - abstraction méta-galactique non triviale en fuite perpétuelle.
Bonjour !
Un consensus semble se faire, autour de la proposition de syntaxe J2. Plus
de détails ici :
http://www.aminus.org/rbre/python/pydec.html
Qu'est-ce que la notion de Decorator ? Je n'ai pas bien vu toute la
subtilité de la chose, mais voici ce qu'il me semble être le plus
compréhensible :
Les decorateurs ajoutent des "choses" aux méthodes ou fonctions, au moment
de leur création (à l'exécution du programme). Les "choses" ajoutées peuvent
de deux types :
- des attributs, qui ne modifient pas les classes/méthodes ; par
exemple l'auteur, ou la version ;
- des "meta-fonctions" qui s'appliquent lors de la création de
l'objet.
Les attributs ajoutent des facilités d'introspection, notamment aux
fonctions ; pour les classes, on pouvait déjà utiliser des attributs de
classes, ou des méthodes de classe et des méthodes statiques (à ne pas
confondre avec les méthodes d'instances).
Les "meta-fonctions" fonctionnent comme suit : soit le decorateur MAJ,
défini par ailleurs, et utilisé sur la fonction FONC. Lors de l'exécution du
programme, on aura, pour la création de FONC :
FONC = MAJ(FONC)
Si jamais j'ai mal compris, prière de me le signaler.
Michel Claveau - abstraction méta-galactique non triviale en fuite perpétuelle. wrote:
Bonjour !
Un consensus semble se faire, autour de la proposition de syntaxe J2. Plus de détails ici : http://www.aminus.org/rbre/python/pydec.html
Qu'est-ce que la notion de Decorator ? Je n'ai pas bien vu toute la subtilité de la chose, mais voici ce qu'il me semble être le plus compréhensible :
Les decorateurs ajoutent des "choses" aux méthodes ou fonctions, au moment de leur création (à l'exécution du programme). Les "choses" ajoutées peuvent de deux types : - des attributs, qui ne modifient pas les classes/méthodes ; par exemple l'auteur, ou la version ; - des "meta-fonctions" qui s'appliquent lors de la création de l'objet.
Les attributs ajoutent des facilités d'introspection, notamment aux fonctions ; pour les classes, on pouvait déjà utiliser des attributs de classes, ou des méthodes de classe et des méthodes statiques (à ne pas confondre avec les méthodes d'instances).
Les "meta-fonctions" fonctionnent comme suit : soit le decorateur MAJ, défini par ailleurs, et utilisé sur la fonction FONC. Lors de l'exécution du programme, on aura, pour la création de FONC : FONC = MAJ(FONC)
Si jamais j'ai mal compris, prière de me le signaler.
Bonne journée La notion de Decorator à t'elle une relation avec le Design Pattern
Decorator ?.
J'ai parfois l'impression que les évolutions futures de Python, vont rendre plus complexe l'apprentissage de ce language, je n'ai pas encore bien assimilé les nouvelles techniques de classes de la version 2.3, et surtout les avantages qu'elles apportent. Pourvu que ce langage ne devienne pas aussi toufu qu'un langage comme Java...
Michel Claveau - abstraction méta-galactique non triviale en fuite
perpétuelle. wrote:
Bonjour !
Un consensus semble se faire, autour de la proposition de syntaxe J2. Plus
de détails ici :
http://www.aminus.org/rbre/python/pydec.html
Qu'est-ce que la notion de Decorator ? Je n'ai pas bien vu toute la
subtilité de la chose, mais voici ce qu'il me semble être le plus
compréhensible :
Les decorateurs ajoutent des "choses" aux méthodes ou fonctions, au moment
de leur création (à l'exécution du programme). Les "choses" ajoutées
peuvent de deux types :
- des attributs, qui ne modifient pas les classes/méthodes ; par
exemple l'auteur, ou la version ;
- des "meta-fonctions" qui s'appliquent lors de la création de
l'objet.
Les attributs ajoutent des facilités d'introspection, notamment aux
fonctions ; pour les classes, on pouvait déjà utiliser des attributs de
classes, ou des méthodes de classe et des méthodes statiques (à ne pas
confondre avec les méthodes d'instances).
Les "meta-fonctions" fonctionnent comme suit : soit le decorateur MAJ,
défini par ailleurs, et utilisé sur la fonction FONC. Lors de l'exécution
du programme, on aura, pour la création de FONC :
FONC = MAJ(FONC)
Si jamais j'ai mal compris, prière de me le signaler.
Bonne journée
La notion de Decorator à t'elle une relation avec le Design Pattern
Decorator ?.
J'ai parfois l'impression que les évolutions futures de Python, vont rendre
plus complexe l'apprentissage de ce language, je n'ai pas encore bien
assimilé les nouvelles techniques de classes de la version 2.3, et surtout
les avantages qu'elles apportent.
Pourvu que ce langage ne devienne pas aussi toufu qu'un langage comme
Java...
Michel Claveau - abstraction méta-galactique non triviale en fuite perpétuelle. wrote:
Bonjour !
Un consensus semble se faire, autour de la proposition de syntaxe J2. Plus de détails ici : http://www.aminus.org/rbre/python/pydec.html
Qu'est-ce que la notion de Decorator ? Je n'ai pas bien vu toute la subtilité de la chose, mais voici ce qu'il me semble être le plus compréhensible :
Les decorateurs ajoutent des "choses" aux méthodes ou fonctions, au moment de leur création (à l'exécution du programme). Les "choses" ajoutées peuvent de deux types : - des attributs, qui ne modifient pas les classes/méthodes ; par exemple l'auteur, ou la version ; - des "meta-fonctions" qui s'appliquent lors de la création de l'objet.
Les attributs ajoutent des facilités d'introspection, notamment aux fonctions ; pour les classes, on pouvait déjà utiliser des attributs de classes, ou des méthodes de classe et des méthodes statiques (à ne pas confondre avec les méthodes d'instances).
Les "meta-fonctions" fonctionnent comme suit : soit le decorateur MAJ, défini par ailleurs, et utilisé sur la fonction FONC. Lors de l'exécution du programme, on aura, pour la création de FONC : FONC = MAJ(FONC)
Si jamais j'ai mal compris, prière de me le signaler.
Bonne journée La notion de Decorator à t'elle une relation avec le Design Pattern
Decorator ?.
J'ai parfois l'impression que les évolutions futures de Python, vont rendre plus complexe l'apprentissage de ce language, je n'ai pas encore bien assimilé les nouvelles techniques de classes de la version 2.3, et surtout les avantages qu'elles apportent. Pourvu que ce langage ne devienne pas aussi toufu qu'un langage comme Java...
Michel Claveau - abstraction méta-galactique non triviale en fuite perpétuelle.
Bonsoir !
Je suis d'accord : il y a une dérive de Python, qui fait fie de sa clarté et sa lisibilité originelle, au profit d'une puissance expressive accrue, mais complexe, qui semble parfois inspirée par la programmation fonctionnelle.
Ceci dit, les notions primordiales (dans le sens primal) de Python continuent de fonctionner. Ouf !
@-salutations -- Michel Claveau
Bonsoir !
Je suis d'accord : il y a une dérive de Python, qui fait fie de sa clarté et
sa lisibilité originelle, au profit d'une puissance expressive accrue, mais
complexe, qui semble parfois inspirée par la programmation fonctionnelle.
Ceci dit, les notions primordiales (dans le sens primal) de Python
continuent de fonctionner. Ouf !
Je suis d'accord : il y a une dérive de Python, qui fait fie de sa clarté et sa lisibilité originelle, au profit d'une puissance expressive accrue, mais complexe, qui semble parfois inspirée par la programmation fonctionnelle.
Ceci dit, les notions primordiales (dans le sens primal) de Python continuent de fonctionner. Ouf !
@-salutations -- Michel Claveau
Michel Claveau - abstraction méta-galactique non triviale en fuite perpétuelle.
Et, pour ceux qui sont intéressés par une certaine programmation fonctionnelle, regardez donc ça : http://candygram.sourceforge.net
Et moi qui appréciait les principes d'Erlang... (http://www.erlang-fr.org/)
Et, pour ceux qui sont intéressés par une certaine programmation
fonctionnelle, regardez donc ça :
http://candygram.sourceforge.net
Et moi qui appréciait les principes d'Erlang...
(http://www.erlang-fr.org/)
Et, pour ceux qui sont intéressés par une certaine programmation fonctionnelle, regardez donc ça : http://candygram.sourceforge.net
Et moi qui appréciait les principes d'Erlang... (http://www.erlang-fr.org/)
Xavier Combelle
Je suis d'accord : il y a une dérive de Python, qui fait fie de sa clarté et sa lisibilité originelle, au profit d'une puissance expressive accrue, mais complexe, qui semble parfois inspirée par la programmation fonctionnelle.
Je ne suis pas d'accord: Le python reste toujours aussi simple pour les taches simples. Il devient plus simple pour les taches complexes.
La complexité ajoutée n'est utile que lorsqu'on a besoin de mettre en place les taches complexes. Et relativement aux autres langages, ces taches complexes restent en général beaucoup plus simples.
De plus, je dirai que les taches complexes très usités deviennent plus simple: par exemple, les "list comprehension" à la place de la fonction map, les generateurs à la place des iterateurs, et maintenant les decorateurs à la plass de l'immonde maMethode = classPath(maMethode) syntaxe qui, en plus d'être pas très belle, peut provoquer des erreurs.
-- Xavier Don't repeat yourself
Je suis d'accord : il y a une dérive de Python, qui fait fie de sa clarté et
sa lisibilité originelle, au profit d'une puissance expressive accrue, mais
complexe, qui semble parfois inspirée par la programmation fonctionnelle.
Je ne suis pas d'accord:
Le python reste toujours aussi simple pour les taches simples.
Il devient plus simple pour les taches complexes.
La complexité ajoutée n'est utile que lorsqu'on a besoin de mettre
en place les taches complexes. Et relativement aux autres langages,
ces taches complexes restent en général beaucoup plus simples.
De plus, je dirai que les taches complexes très usités deviennent plus
simple: par exemple, les "list comprehension" à la place de la fonction
map, les generateurs à la place des iterateurs, et maintenant les
decorateurs à la plass de l'immonde
maMethode = classPath(maMethode)
syntaxe qui, en plus d'être pas très belle, peut provoquer des erreurs.
Je suis d'accord : il y a une dérive de Python, qui fait fie de sa clarté et sa lisibilité originelle, au profit d'une puissance expressive accrue, mais complexe, qui semble parfois inspirée par la programmation fonctionnelle.
Je ne suis pas d'accord: Le python reste toujours aussi simple pour les taches simples. Il devient plus simple pour les taches complexes.
La complexité ajoutée n'est utile que lorsqu'on a besoin de mettre en place les taches complexes. Et relativement aux autres langages, ces taches complexes restent en général beaucoup plus simples.
De plus, je dirai que les taches complexes très usités deviennent plus simple: par exemple, les "list comprehension" à la place de la fonction map, les generateurs à la place des iterateurs, et maintenant les decorateurs à la plass de l'immonde maMethode = classPath(maMethode) syntaxe qui, en plus d'être pas très belle, peut provoquer des erreurs.
-- Xavier Don't repeat yourself
Michel Claveau - abstraction méta-galactique non triviale en fuite perpétuelle.
Bonjour !
Justement, parlons des listes en intension. Lequel des deux scripts suivants est le plus lisible ?
1) s='AZERTY' a = [b for b in s] print a
2) s='AZERTY' a = [] for b in s: a.append(b) print a
Bonjour !
Justement, parlons des listes en intension.
Lequel des deux scripts suivants est le plus lisible ?
1)
s='AZERTY'
a = [b for b in s]
print a
2)
s='AZERTY'
a = []
for b in s:
a.append(b)
print a
Justement, parlons des listes en intension. Lequel des deux scripts suivants est le plus lisible ?
1) s='AZERTY' a = [b for b in s] print a
2) s='AZERTY' a = [] for b in s: a.append(b) print a
Wilk
"Michel Claveau - abstraction méta-galactique non triviale en fuite perpétuelle." writes:
Bonjour !
Justement, parlons des listes en intension. Lequel des deux scripts suivants est le plus lisible ?
1) s='AZERTY' a = [b for b in s] print a
2) s='AZERTY' a = [] for b in s: a.append(b) print a
Si tu remplace 1) par
print [b for b in 'AZERTY'] ou mieux print list('AZERTY') (on pourait dire qu'il fait doublon aussi)
tu gagne quand même pas mal de lignes par rapport à 2), ce qui fait que *l'ensemble du programme* est plus lisible. Même si paradoxalement cette ligne là est moins lisible...
-- Wilk - http://flibuste.net
"Michel Claveau - abstraction méta-galactique non triviale en fuite perpétuelle." <unseulmcmcmcmc@msupprimerlepoint.claveauPOINTcom> writes:
Bonjour !
Justement, parlons des listes en intension.
Lequel des deux scripts suivants est le plus lisible ?
1)
s='AZERTY'
a = [b for b in s]
print a
2)
s='AZERTY'
a = []
for b in s:
a.append(b)
print a
Si tu remplace 1) par
print [b for b in 'AZERTY']
ou mieux
print list('AZERTY') (on pourait dire qu'il fait doublon aussi)
tu gagne quand même pas mal de lignes par rapport à 2), ce qui fait que
*l'ensemble du programme* est plus lisible. Même si paradoxalement cette
ligne là est moins lisible...
"Michel Claveau - abstraction méta-galactique non triviale en fuite perpétuelle." writes:
Bonjour !
Justement, parlons des listes en intension. Lequel des deux scripts suivants est le plus lisible ?
1) s='AZERTY' a = [b for b in s] print a
2) s='AZERTY' a = [] for b in s: a.append(b) print a
Si tu remplace 1) par
print [b for b in 'AZERTY'] ou mieux print list('AZERTY') (on pourait dire qu'il fait doublon aussi)
tu gagne quand même pas mal de lignes par rapport à 2), ce qui fait que *l'ensemble du programme* est plus lisible. Même si paradoxalement cette ligne là est moins lisible...
-- Wilk - http://flibuste.net
Meles
Wilk wrote:
tu gagne quand même pas mal de lignes par rapport à 2), ce qui fait que *l'ensemble du programme* est plus lisible. Même si paradoxalement cette ligne là est moins lisible...
Bonsoir, et y a t'i une différence de performance entre les 2 écritures (je me doutes un peu de la réponse, mais j'aimerai confirmation).
Cordialement
Blaise
Wilk wrote:
tu gagne quand même pas mal de lignes par rapport à 2), ce qui fait que
*l'ensemble du programme* est plus lisible. Même si paradoxalement cette
ligne là est moins lisible...
Bonsoir,
et y a t'i une différence de performance entre les 2 écritures (je me
doutes un peu de la réponse, mais j'aimerai confirmation).
tu gagne quand même pas mal de lignes par rapport à 2), ce qui fait que *l'ensemble du programme* est plus lisible. Même si paradoxalement cette ligne là est moins lisible...
Bonsoir, et y a t'i une différence de performance entre les 2 écritures (je me doutes un peu de la réponse, mais j'aimerai confirmation).
Cordialement
Blaise
Michel Claveau - abstraction méta-galactique non triviale en fuite perpétuelle.
Bonsoir !
Meles : La liste en intention est plus rapide. Mais ce n'est pas l'objet de ce débat.
Wilk : si tu veux gagner (un peu) des lignes, il est possible d'écrire :
a=[] for b in 'AZERTY': a.append(b) print a
En gardant une excellente lisibilité.
Et puis, si l'on cherche des programmes ultra-court, autant passer à Perl, ou Ocaml (ou Haskell). Mais alors, la lisibilité semble inversement proportionnelle au nombre de lignes.
Et puis le nombre de lignes n'est plus considéré comme significatif depuis les années 70, comme l'a brillamment démontré le langage INTERCAL.
Et puis, pour faire vraiment court, je te conseille le langage BrainFuck : les programmes ne font toujours qu'une ligne. Mais, là aussi, la lisibilité est amusante.
@-salutations -- Michel Claveau
Bonsoir !
Meles : La liste en intention est plus rapide. Mais ce n'est pas l'objet de
ce débat.
Wilk : si tu veux gagner (un peu) des lignes, il est possible d'écrire :
a=[]
for b in 'AZERTY': a.append(b)
print a
En gardant une excellente lisibilité.
Et puis, si l'on cherche des programmes ultra-court, autant passer à Perl,
ou Ocaml (ou Haskell). Mais alors, la lisibilité semble inversement
proportionnelle au nombre de lignes.
Et puis le nombre de lignes n'est plus considéré comme significatif depuis
les années 70, comme l'a brillamment démontré le langage INTERCAL.
Et puis, pour faire vraiment court, je te conseille le langage BrainFuck :
les programmes ne font toujours qu'une ligne. Mais, là aussi, la lisibilité
est amusante.
Meles : La liste en intention est plus rapide. Mais ce n'est pas l'objet de ce débat.
Wilk : si tu veux gagner (un peu) des lignes, il est possible d'écrire :
a=[] for b in 'AZERTY': a.append(b) print a
En gardant une excellente lisibilité.
Et puis, si l'on cherche des programmes ultra-court, autant passer à Perl, ou Ocaml (ou Haskell). Mais alors, la lisibilité semble inversement proportionnelle au nombre de lignes.
Et puis le nombre de lignes n'est plus considéré comme significatif depuis les années 70, comme l'a brillamment démontré le langage INTERCAL.
Et puis, pour faire vraiment court, je te conseille le langage BrainFuck : les programmes ne font toujours qu'une ligne. Mais, là aussi, la lisibilité est amusante.
@-salutations -- Michel Claveau
Meles
Michel Claveau - abstraction méta-galactique non triviale en fuite perpétuelle. wrote:
Meles : La liste en intention est plus rapide. Mais ce n'est pas l'objet de ce débat.
Au risque de paraitre lourd, si j'ai bien tout suivi, la liste en intention
est la méthode numéro 1 des exemples précédent?
Cordialement
Blaise
Michel Claveau - abstraction méta-galactique non triviale en fuite
perpétuelle. wrote:
Meles : La liste en intention est plus rapide. Mais ce n'est pas l'objet
de ce débat.
Au risque de paraitre lourd, si j'ai bien tout suivi, la liste en intention
