* “en lui passant des paramètres” -> “en lui passant des arguments” (cf. http://sametmax.com/la-difference-entre-parametres-et-arguments/);

* “L’autocompletion” -> “L’autocomplétion”;

* “contient maitenant” -> “contient maintenant”;

* “Fonction avec arguments” -> “Fonction avec paramètres” (je sais, je fais chier)? Dans ce titre, on parle de la définition de la fonction, donc de paramètres, non?;

* “J’ai des arguments regarde” -> “J’ai des arguments, regarde” (la virgule^^) (dans le code et dans les commentaires);

* “à la fonctions décorée” -> “à la fonction décorée”;

* “éxécuté” / “éxécuter” -> “exécuté” / “exécuter” (10 fois);

* “En fait ce decorateur” -> “En fait ce décorateur”;

* “quand on décore la )fonction” -> “quand on décore la fonction” (dans le code uniquement);

* “Je créé des décorateur” -> “Je créé des décorateurs” (dans le code uniquement);

* “les variables intermédiares” -> “les variables intermédiaires”;

* “ça aiderait quand même….” -> “ça aiderait quand même…”;

* “débugger” -> “déboguer”.

Un compter qui compte et affiche le nombre de fonction qu’une fonction

Un peu trop de copier/coller ;-)

Un compte*u*r qui compte et affiche le nombre de fo*is* qu’une fonction

(d’ailleur “un compteur qui compte” c’est pas très orginal^^)

Mais attention, si vous acceptez *args, **kwargs, la liste des arguments ne sera plus disponible pour l’introspection. C’est quelque chose que @wraps ne peut pas changer. La plupart du temps, c’est un compromis acceptable.

Compromis acceptable, sauf si l’on génère sa doc avec Sphinx.

J’étais assez triste de voir toutes mes méthodes décorées prendre *args, **kwargs comme arguments du coup.

Et puis je suis tombé sur ce snippet qui permet de dewrapper le wrapper (si on utilise functools.wraps):

http://stackoverflow.com/a/28371786

Ouf !

@decorateur 
def fonction()

Va faire :

fonction = decorateur(fonction)

Alors que

@decorateur()
def fonction()

Va faire :

fonction = decorateur()(fonction)

On a un niveau de plus d’imbrication de wrapper, et donc de fonctions dynamiquement créés. C’est comme inception, c’est plus compliqué quand on rajoute des couches.

Note qu’un décorateur qui doit être appelé ne s’écrit pas pareil, puisqu’il doit retourner une fonction qui doit retourner une fonction.

Je vois cette ligne:
”

Vous noterez qu’on a utilisé la notation @, avec un appel de fonction: @createur_de_decorateur() et non @createur_de_decorateur !

”

Salut , je ne comprends pas ce que ca change? j’ai essayé sans et ca na marche pas mais je ne comprends pas du tout pourquoi

merci

Les deux examples ont deux raison différentes de ne pas fonctionner.

Le premier c’est que les types de bases sont protégés contre les modifications. Quand je dis protégés, c’est pas non plus un coffre fort puisqu’avec un peu d’astuce on peut le faire, mais ça évite de le faire par erreur. C’est notament pour éviter des mauvaises pratiques comme le monkey patching des types de base qu’on peut voir en ruby et javascript et qui entrainent après des casse-tête de debug quand 2 libs le font.

Le second exemple ne fonctionne pas car tu essaye de LIRE un attribut qui n’existe pas encore dans ton if. Ca ne marche sur AUCUN objet en Python. Par contre, tu peux parfaitement initialiser ton attribut à une valeur avant ta condition, et ça marchera. Les fonctions peuvent avoir des attributs arbitraires en Python, on s’en sert beaucoup dans les décorteurs, par exemple je l’utilise avec django quicky.

@goearges : merci