Dissidents - python

Les property

Pmol — Sat, 01 Sep 2007 16:27:00 +0000

Ou comment appeler une fonction lorsque l'on accède à un attribut.

Prenons un exemple. Vous avez une classe Rectangle qui a deux attributs : longueur et largeur. Vous pouvez les redéfinir à volonté, bien.

>>> class Rectangle(object):
...     def __init__(self, longueur, largeur):
...             self.longueur = longueur
...             self.largeur = largeur
... 
>>> a = Rectangle(10, 1)
>>> a.longueur
10
>>> a.longueur = 15
>>> a.longueur
15

Mais s'il vous prend l'idée subite et stupide d'ajouter un attribut aire, comment allez-vous faire pour que sa valeur soit toujours exacte ? Si vous modifiez la longueur du rectangle, il y aura un problème.

>>> a.aire = a.longueur * a.largeur
>>> a.aire
15
>>> a.largeur = 3
>>> a.aire
15

Bien que la largueur du rectangle ait changée, l'aire n'a pas bougé d'un poil. C'est un comportement normal (c'est une simple variable), mais ce n'est pas le comportement souhaité. On peut utiliser une fonction trouverAire() ou aire(), mais c'est nettement moins sex' qu'une variable non ?

Mais Python nous offre (comme d'autres langages) une solution adaptée à notre problème : les properties. Grâce au type prédéfini property, on va pouvoir créer un attribut spécial de la classe Rectangle, qui sera (du côté utilisateur de la classe) identique à un attribut simple. Cet attribut est spécial dans le sens où, lorsqu'on veut accéder à sa valeur, la modifier ou le supprimer, on passe part des fonctions. Même si vous vous en foutez sûrement, voici la signature de property

property(fget = None, fset = None, fdel = None, doc = None) -> property attribute

fget est appelé quand on demande la valeur de l'attribut, fset lorsqu'on affecte à l'attribut une valeur et fdel quand on veut supprimer l'attribut. doc est l'éventuelle docstring de l'attribut.

Si on reprend notre exemple de rectangles, lorsque l'utilisateur va demander la valeur de l'aire de notre rectangle, Python appellera une fonction prédéfinie qui va renvoyer, après calcul, la valeur de l'aire. Cette valeur sera toujours correcte, puisque recalculée à chaque demande. Exemple :

>>> class Rectangle(object):
...     def __init__(self, largeur, hauteur):
...             self.largeur = largeur
...             self.hauteur = hauteur
...     def _getAire(self):
...             return self.largeur * self.hauteur
...     aire = property(_getAire)
... 
>>> a = Rectangle(10, 5)
>>> a.aire
50
>>> a.largeur = 3
>>> a.aire
15

Ici, chaque instance la classe Rectangle a un attribut aire en lecture seule (si un des trois paramètres n'est pas donné, alors l'opération correspondante lève une exception), recalculé à chaque demande.

Du code en Python

Poulet — Sun, 22 Jul 2007 09:19:00 +0000

Parce que trop de sucre rend ~~idiot~~ diabétique. Visit my website.

Debout les gars, réveillez-vous !

Poulet — Mon, 02 Jul 2007 07:23:00 +0000

Salut les poulpes. Ouaaaaais ! firent les poulpes.

Comme vous êtes un peu morts ces jours-ci, un petit truc pour vous détendre les zygomatiques, à vous, oui, vous qui ne pratiquez pas des langages pseudo-fonctionnels, mais des vrais langages de mâles.

Dans un langage normal, disons, "sympa", on aurait ça : let sommelong = map length. C'est lisible (sous réserve d'un peu d'habitude peut-être), c'est efficace. Après, on rigole bien, on a une fonction de type [[a]] -> [Int], on peut écrire sommelong [[1, 2, 3], [3,4]] aussi bien que sommelong ["Foo", "BarBarBar"], ce qui est totalement inutile (ça prouve bien que mon exemple est à chier), mais c'est bien et tout. Pour les étrangers incultes et barbares, c'est une application partielle : map est de type (a -> b) -> [a] -> [b], c'est à dire que son premier argument est une fonction prenant un type a quelconque (enfin, je crois) et renvoyant un type b tout aussi quelconque (même pas forcément le même). Or si on écrit map length (comme on l'a fait juste au début, ça n'est pas un hasard), on crée une nouvelle valeur fonctionnelle qui correspond à un map dont le premier argument est length - cependant cette valeur fonctionnelle est directement utilisable comme fonction. On peut donc lui nommer un nom (comme on a fait) et l'appliquer après à des listes (comme on a fait aussi), genre sommelong uneliste. C'est comme si l'on avait fait map length uneliste.

Dans un langage moins sympa (zB. Python) mais qui essaye de se faire des potes poulpes (Ouaaaaais !), on est bien emmerdé, parce que :

On a bien une fonction map, qui prend en argument une fonction et une liste (en fait, "pas seulement", mais compliquons pas, tfaçon ça marche).
On a bien une fonction len, qui sert à calculer la longueur d'une séquence^W liste.
Mais on sait pas comment combiner les deux.

On pourrait faire une fonction chiante qui se tape ce rôle, mais ça sert à rien que je le fasse puisque la doc officielle donne de toute façon le code correspondant. Moi, je voulais juste vous dire que ça existe, sous le nom de functools.partial dans Python 2.5 :

>>> import functools
>>> sommelong = functools.partial(map, len)
>>> sommelong([[1,2,3], "foo"])
[3, 3]

L'exemple est toujours foireux, mais vous êtes cultivé (ou hilare, ce qui est bien aussi).

Voici donc la page officielle de functools.

C'est puissant.

Des nouvelles de mon suicide.

Poulet — Mon, 04 Jun 2007 20:53:00 +0000

Non j'déconne.

Un gens normal, il poste pas sur le blog, tu lui dis "Hé, allez rolol va poster sur le blog". Moi c'est "Ah au fait, tu postes plus ?" "Non, pas d'inspiration" "Ouais c'est ce qu'on se disait.". Hyper chaleureux, merci Cygal.

Pour la peine, un lien inutile mais fendard. Peut éventuellement être utilisé pour la source qui se trouve au bout, même si je doute qu'elle présente de l'intérêt. En même temps je sais pas, je l'ai pas lue.

Maintenant, un vrai contenu (parce qu'en fait des sujets j'en ai plein, hein, j'ai juste pas envie de les partager avec vous). Je vais vous parler d'un système de typage utilisable en Python, qui présente un intérêt moyen puisqu'il reste dynamique, mais quand même. Il s'agit de traits, NON ne cliquez pas, lisez la suite (je comprends pourquoi vous foutez les liens à la fin maintenant :o).

Pour paraphraser plus ou moins bluestorm et l'éditeur du papier officiel qui cause de traits, Python utilise un système de typage dynamique, et si c'est assez cool pour un langage de scripts, ça peut être chiant pour de plus gros projets. Ouais, y'a des gens qui font des gros projets en Python, faute de langage plus crédible, ou de compétence/sérieux. On en trouve cela dit des très biens, hein, et pas que des trucs de webeux, sans viser personne bien sûr. J'vous emmerde de toute façon.

Un tel déchaînement de violence, ça fout les boules.

Bref, parmis les gros projets Python, on compte Chaco (flash). Attention, lien rigolo, haha (un vrai lien vers Chaco (pdf)). Au moment où j'écris j'ai plus trop l'impression que ça soit une killer app en Python, mais on va dire que si. Or donc, Chaco vous permet (à première vue) d'utiliser plot depuis Python, pour des raisons qui me dépassent vu que je n'utilise pas plot. Ça serait comme qui dirait bâti par dessus.

Mais le problème, c'est que les utilisateurs de Chaco (et là on va faire le lien avec le ~~début~~ milieu de l'article) peuvent être enclins à taper n'importe quoi pour, par exemple, changer un objet de couleur. Et faut bien les comprendre : c'est pratique de pouvoir faire monObjet.color = "red" ou monObjet.color = (1.0, 0.0, 0.0, 1.0) (encore que le dernier est chiant à taper - heureusement que je l'ai directement copié-collé de la page que vous n'êtes pas allé voir). C'est ce qu'on appelle être flexible.

Dans un langage qui l'est naturellement (et souvent un peu trop), c'est pas difficile à faire. Ce qui devient plus chiant, c'est quand on veut contrôler les valeurs que peut prendre color. Par exemple, un quatrain (mettons que ça s'appelle comme ça) avec des valeurs qui ne sont pas comprises entre 0 et 1, ça n'a aucun sens. On pourrait alors imaginer un système de contrôle de l'attribut color à l'aide des propriétés (oui on sait lasts, en définissant une méthode color= :]). Ça fait quand même pas mal de code à implémenter, avec à chaque fois pour seule éventuelle différence les types acceptés.

Donc, autant utiliser un module qui le fait déjà, non ? Et qui, en passant, l'implémente certainement de cette façon (n'avez qu'à regarder). Bien. Passons à l'exemple d'utilisation (qui est encore une fois un exemple officiel), qui me permettra d'introduire quelques particularités liées à traits :

from enthought.traits.api import Delegate, HasTraits, Int, Str, Instance

class Parent(HasTraits): # Le typage se fait en héritant... ce qui le restreint aux classes. Mais bon.
    first_name = Str('') # Sans surprise, on utilise deux chaînes (qu'on initialise aux chaînes vides
    last_name = Str('') 
                                 
class Child(HasTraits):
    age = Int # Ici, un âge entier, sans intialisation.
    father = Instance(Parent) # On peut utiliser des classes comme nouveaux types.
    first_name = Str('')

    last_name = Delegate('father') # Le nom est celui du père ;) 

    def _age_changed(self, old, new):  # Une particularité de traits (voir plus bas)
        print 'Age changed from %s to %s ' % (old, new)

joe = Parent()
joe.last_name = 'Johnson'

# Ici, on crée un enfant, et le nom de famille sera bel et bien transmis.
moe = Child()
moe.father = joe
print "Moe's last name is %s" % (moe.last_name)

# On change l'âge normalement, et... la méthode _age_changed sera appelée
moe.age = 10

# La ligne suivante provoquera une erreur
moe.age = 12.3

Voilà voilà. Le code se comprend facilement, même pour les non-pythonnistes que sont en majorité les hérétiques qui lisent ce blog. On observe trois points importants, qui sont d'ailleurs signalés en commentaires dans le code source original, et que je vais retranscrire ici : le rôle de traits ne se limite pas au typage. C'est son but premier, que les développeurs ont appelé la “validation”. C'est ce rôle qui fera que la dernière ligne provoquera une erreur (12.3 n'étant pas un entier). Ici, les exemples d'utilisation sont basiques, mais je vous invite à consulter le site officiel si vous souhaitez en voir des plus intéressants (on peut par exemple créer des types sommes, ou des types d'entiers compris dans un certain intervalle, ou des structures de données typées (List(Int) par exemple), etc.)

Mais traits ne se limite pas à ça. Il propose aussi ce qu'on appelle la “délégation”. En l'occurence, on la voit assez facilement avec l'appel de Delegate : une classe peut hériter certaines caractéristiques (on dira "certains traits"...) d'une autre, sans pourtant passer par un héritage habituel.

Le troisième point présenté ici est la “notification” : on peut définir un comportement qui sera adopté lors de la modification d'un trait. Cela se fait en passant par une méthode qui, si elle est implémentée, devra être prête à recevoir l'ancienne et la nouvelle valeur du trait.

Bon, vous allez me dire que vous vous ennuyez vraiment, que tout ceci ne vous intéresse pas. Moi non plus, pas trop, en fait. Mais il reste un dernier point, que je n'ai pas présenté ici parce que le code d'exemple ne fonctionne pas chez moi, que les développeurs on appelé la “visualisation”. Via un module appelé traits.ui, on peut en effet définir une façon purement sémantique de représenter ses données dans une interface graphique. On donne alors la possibilité de construire une interaction avec l'utilisateur final du programme, standardisée et sans fioritures (du moins pour une utilisation basique), donc évidente et régulière. On peut interroger cet utilisateur sur la valeur qu'il souhaite donner à un certain trait, en profitant immédiatement des trois autres particularités développée précédemment. Bon, ça a une gueule sacrément austère, mais comme je vous le disais je ne suis pas sûr que ça ne soit pas modifiable pour une utilisation avancée.

Pour les personnes qui se sont vraiment emmerdées jusqu'à présent, je reviens juste quelques secondes sur le côté “délégation”. En effet, si ici les traits semblent être une joyeuse API visant à combler certaines lacunes du langage, ils sont en réalité un objet de recherche, qu'on veut utiliser dans des langages orientés objet qui pratiquent l'héritage multiple (et où, presque par définition, ça pose problème), ou même dans des langages plus raisonnables. Ils sont alors présentés comme une façon d'échapper aux problèmes de cet héritage multiple, et comme des entités dont l'utilisation permet de factoriser le code, de regrouper des comportements (mais pas des états) communs à plusieurs classes.

Voici donc un court article à ce sujet (caml inside) (pdf), qui pourra donner envie au lecteur de lire un article un peu plus riche (pdf). Ils présentent notamment (surtout le deuxième) les faiblesses des mécanismes d'héritage multiple, et l'utilisation des traits en tant que solution.

NB : Vous comprenez pourquoi j'écris plus, ça sert vraiment à rien.

Vlà une idée qu'elle est pas terrible

Poulet — Sat, 19 May 2007 11:52:06 +0000

La tarte, ça appelle le poulet. Ou “comment contre-attaquer avant qu'il se soit rien passé”.

Bien le bonjour. Une fois n'est pas coutume, je viens de trouver le moyen d'être chiant, d'une part en étant plus productif que mes collègues, d'autre part en produisant de l'inutilité.

Vlà-t'y pas que pas plus tard qu'hier, sur le canal où nous nous retrouvons pour le moment (#sdz-unix sur irc.epiknet.org), ArtMoonik a une super idée (comme ça lui arrive souvent d'ailleurs), et ne résiste pas au plaisir de nous en faire part :

ArtMoonik: va falloir qu'on floode de ruby

Si c'est pas génial, ça, madame.

Donc moi, naturellement pas trop favorable à la chose, je prends sur moi, et réfléchis. Et là je me dis : "mais on n'a qu'à faire l'inverse !".

Ce que j'essaye de dire au moyen de mon immarcescible talent de comédien-metteur en scène (si, on peut placer immarcescible dans cette phrase, je vois pas le problème), ce que désormais, tous les jours sauf le dimanche (d'où l'intérêt de commencer un samedi), j'aurai la joie de vous infliger “Le Truc En Python Du Jour”. Ça va être pénible, inutile, je doute tenir la longueur, mais ça me fera une raison pour faire de la pub pour le blog : “Hé, toi qui kiffes le Python, tu savais ça ? Et ça ?”.

Permettez-moi donc d'introduire le premier de cette longue liste de scripts (ou de bouts de) niaiseux : kamoulox.rb.py. C'est une traduction du script kamoulox d'ArtMoonik. Vous devriez pouvoir à peu près tout lire, mais détaillons un petit peu.

Le début me semble à peu près compréhensible, on note la traduction de empty? des chaînes par une comparaison avec la chaîne vide, celle du mystérieux caractère 35 par un '#' (parce que oui ce sont les mêmes), un "strippage" quasi inutile (mais j'aime bien) sur clef et contenu, la traduction une nouvelle fois du empty? sur le hash par un truc un peu plus riche sémantiquement parlant (ne niez pas §§), et l'utilisation d'une fonction nommée (définie de façon interne) pour sub, là où Ruby utilise un bloc (encore une fois si on avait de vraies lambdas en Python...). De plus, plutôt que de rajouter une méthode à list (ce qui aurait été compliqué vu que c'est pas possible par défaut), on utilise choice du module random. On note également que ce que sub transmet à la fonction qu'il invoque, c'est un objet match, pas une chaîne.

La fonction sub permet donc d'appeler une fonction (ici, on peut aussi lui transmettre une chaîne de remplacement à la place) en lui passant le résultat d'une capture à l'aide d'une regex. Ici, la regex [(\w)_\|]* qu'elle est belle sert à capter tous les mots, plus les _ et les |.

Voilà voilà, ce script est un peu plus compliqué que ce qui suivra (normalement), étant donné que je montrerai par la suite plus "d'astuces" Pythonniques que de vrais programmes, mais on ne sait jamais.