objet passe partout

Version imprimable

objet passe partout

Bonjour,

Voici une petite classe dont le but est d’être utilisée comme proxy de n'importe quoi. Son but est de "passer partout", i.e ne pas lever d'erreur lorsqu'elle est utilisée à la place de l'objet attendu.

Voyez une fonctionnalité que j'aurais oublié, ou une amélioration quelconque ?
Merci d'avance.

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
 
class PassePartout:
    """Universal Proxy Object"""
    _exemple= None
    def __init__(self): pass
    def __getattr__(self,key):
        if key== "__str__": return "PassePartout"
        if key== "__repr__": return "PassePartout"
        return PassePartout()
    def __setattr__(self,key,value): pass
    def __getitem__(self,key):  return PassePartout()
    def __setitem__(self,key,value):
        pass
    def __str__(self):return "PassePartout"
    def __repr__(self):return "PassePartout"
    def __hash__(self):    
        """same hashcode for every instance"""
        if PassePartout._exemple is None:
            PassePartout._exemple= PassePartout()
        return object.__hash__(PassePartout._exemple)
    def __call__(self,*args,**kwargs): return PassePartout()
    def __nonzero__(self,*args,**kwargs): return True
    def __coerce__(self,other):
        this= None
        if other.__class__== float(1.0).__class__: this= 0.0
        if other.__class__== int(1).__class__: this= 0
        return (this,other)

23/12/2011, 11h23
PauseKawa

Bonjour VV33D,

Je ne vois pas trop l'utilité (Un exemple pour me mettre sur la voie ?) mais je me dit que si l'objet est itérable cela risque de durer un moment.

@+
23/12/2011, 14h24
afranck64

pourqu'il soit "passe partout" il devra impérativement toujours répondre True à isinstanceof et là...

Si une string me répond True lorsque je demande un Canvas les carottes pourraient bien cuir. :mouarf:
23/12/2011, 16h56
wiztricks
Salut

object est déjà là pour çà (ou plutôt qu'ajoute PassePartout à object qui le rende "intéressant")
Code:

1 2 3 4 5 6 7 8 9 10 >>> class A: pass ... >>> a = A() >>> isinstance(a, object) True >>> a <__main__.A object at 0x025BBE90> >>> isinstance('bla', object) True >>>
Note: je ne dis pas que cela ne sert à rien, juste que je n'ai pas compris à quoi... Je n'ai pas retrouvé un post de Dividee sur un sujet analogue (proxy).

- W
23/12/2011, 17h17
afranck64
Mes pensées étaient plutôt:
Code:

1 2 3 partout = PassePartout() isinstance(partout, str) #True isinstance(partout, Canvas) #True
ps:
~~isinstanceof~~ isinstance (Ma lecture de java me monte à la tête :aie:)
24/12/2011, 12h04
dividee

Je ne comprends pas très bien l'usage moi non plus.
Si c'est un proxy, comment est-il initialisé ? (un proxy renvoie à autre chose).
Si c'est un "trou noir" (un objet qui retourne toujours lui-même, quel que soit l'opération qu'on lui applique), pourquoi ne pas en faire un singleton ?
Pourquoi "return PassPartout()" et pas "return self" ?
24/12/2011, 12h09
PauseKawa

Citation:

Envoyé par dividee

Si c'est un proxy, comment est-il initialisé ? (un proxy renvoie à autre chose).

Je pense que pour VV33D c'est _exemple

Citation:

Envoyé par dividee

Pourquoi "return PassPartout()" et pas "return self" ?

C'est cela le trou noir pour moi...

Ce n'est pas un proxy, c'est une 'yes class' ;)
24/12/2011, 12h39
dividee

Citation:

Envoyé par PauseKawa

Je pense que pour VV33D c'est _exemple

Si c'était le cas, __getattr__ devrait utiliser _exemple. Le seul endroit où il est utilisé c'est dans __hash__, et là on voit qu'il est initialisé à une instance de PassePartout... Je ne vois pas trop à quoi ça rime...

A quoi cela sert de créer de nouvelles instances alors qu'aucun attribut ne les distinguent ? Est-ce l'histoire du "borg pattern" qui remplace le singleton ? Il me semble que ça n'apporte rien ici.
24/12/2011, 13h16
PauseKawa

C'est bien pour cela que je l'appelle une 'yes class': Elle ne fait pas référence au sujet et répond toujours oui.
Je pense qu'il vas falloir attendre des explications de VV33D.
24/12/2011, 18h43
afranck64

Citation:

Envoyé par PauseKawa

C'est bien pour cela que je l'appelle une 'yes class': Elle ne fait pas référence au sujet et répond toujours oui.
Je pense qu'il vas falloir attendre des explications de VV33D.

Je suis d'accord pour la "yes/True-class". Mais une chose me trotinne à la tête. Est-il possible de mettre au point une "True-instsnce" class? qui retourne toujours <True> lorsque l'on fait:

Code:

isinstance(obj, TrueClass)

? Je n'ai pas vu de méthode "magique" genre __isinstance__ permettant de le faire. Est-ce possible?
25/12/2011, 05h53
PauseKawa
Bonjour afranck64,

C'est dans la réponse de wiztricks:
(2.x)
Code:

1 2 3 4 5 6 7 8 class dummy: pass myobj = PassePartout() print(isinstance(dummy, myobj)) print(isinstance(list, myobj)) print(isinstance(dummy, object)) print(isinstance(list, object))
Code:

1 2 3 4 True True True True
Il me semble que c'est dans la doc de 'type' ou un Proposal.

Sur ce je retourne à mes occupations (ho, ho, ho) et bonnes fêtes @ll ;)
25/12/2011, 11h07
PauseKawa

Bonjour,

@afranck64: J'avais oublier: __instancecheck__ (et __subclasscheck__)

@+

Edit:
Source
(A lire aussi au passage)
Edit pour le lien direct customizing-instance-and-subclass-checks
25/12/2011, 16h29
afranck64

Citation:

Envoyé par PauseKawa

: __instancecheck__ (et __subclasscheck__)

Exactement ce à quoi je pensais. :mrgreen:
25/12/2011, 22h11
fred1599

En fait c'est quoi l'intérêt de cette classe?

Le PO parle de proxy, et si on parle de ce terme, je le vois comme une tour de contrôle (qui sait dire oui mais aussi non) entre deux machines.

Dire oui à tous ne donne plus l'intérêt d'un proxy, je me trompe?
26/12/2011, 07h26
PauseKawa

Bonjour fred1599,

Ce n'est pas un proxy car il n'y a pas de référence à l'objet sujet.
Le code semble (je dis semble dans l'absence de réponse du PO, fêtes oblige sans doute) être là pour écraser la référence d'un objet par PassePartout.
C'est effectivement l’intérêt de la chose que nous recherchons.

Si c'est vraiment pour faire de l'universel je trouve cela dangereux.
Comme dit plus haut l’absence de référence fait que cela vas planter à un moment donné (itération, ValueError sur les attributs de la classe remplacée, etc).

Si c'est pour remplacer quelques objets connus alors autant faire un vrais proxy (Explicit is better than implicit)

En Python le programmeur est considéré comme responsable et dans ce sens il lui est donné un grande liberté de tester, même dans des cas bien spéciaux de la machinerie interne: perso j'adore cela.
Je classerais donc cela dans la case expérimental.

@+

Edit: Reste le quizz du return PassePartout()
26/12/2011, 10h35
fred1599

Salut PauseKawa

Citation:

Ce n'est pas un proxy car il n'y a pas de référence à l'objet sujet.

Ah je me disais aussi :)

J'attend de voir la réponse du PO pour en dire plus...

Bonsoir,

Citation:

Envoyé par fred1599

J'attend de voir la réponse du PO pour en dire plus...

Et si on en profitais pour lui répondre au passage ?
15 réponses mais aucune dans le sens de sa question... On n'est pas très bon sur le coup :oops:. De plus cela vas nous permettre d'apprendre aussi au passage.

Pour l'itérable que pensez vous de:

Code:

1
2
3
4
5
6
7
8
9
10
11
12
    def __len__(self):
        return 0
 
    len = __len__
 
    def __next__(self):
        raise StopIteration
 
    next = __next__
 
    def __iter__(self):
        return self

Code:

1
2
3
4
5
6
myobj = PassePartout()
if len(myobj):
    for e in myobj:
        print(e)
for e in myobj:
    print(e)

Edit:
@VV33D
Ne pense tu pas que c'est plus lisible comme cela ?

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
class PassePartout:
    """Universal Proxy Object"""
 
    _exemple= None
 
    def __init__(self):
        pass
 
    def __getattr__(self, key):
        if key== "__str__":
            return "PassePartout"
        if key== "__repr__":
            return "PassePartout"
        return PassePartout()
 
    def __setattr__(self, key, value):
        pass
 
    def __getitem__(self, key):
        return PassePartout()
 
    def __setitem__(self, key, value):
        pass
 
    def __str__(self):
        return "PassePartout"
 
    def __repr__(self):
        return "PassePartout"
 
    def __hash__(self):    
        """same hashcode for every instance"""
        if PassePartout._exemple is None:
            PassePartout._exemple= PassePartout()
        return object.__hash__(PassePartout._exemple)
 
    def __call__(self, *args, **kwargs):
        return PassePartout()
 
    def __nonzero__(self, *args, **kwargs):
        return True
 
    def __coerce__(self, other):
        this = None
        if other.__class__== float(1.0).__class__:
            this = 0.0
        if other.__class__== int(1).__class__:
            this = 0
        return (this, other)
 
    def __len__(self):
        return 0
 
    len = __len__
 
    def __next__(self):
        raise StopIteration
 
    next = __next__
 
    def __iter__(self):
        return self
 
 
myobj = PassePartout()
if len(myobj):
    for e in myobj:
        print(e)
for e in myobj:
    print(e)

C'est sans doute une question de goût puisque cela passe avec l'interpréteur mais bon... import this.

@+

26/12/2011, 19h13
fred1599
Citation:

Envoyé par PauseKawa

Et si on en profitais pour lui répondre au passage ?

Oui je veux bien, c'est le principe du forum, mais je ne suis pas sûr de comprendre ce qu'il veut dire par proxy.

En fait peux-tu me dire clairement ce qu'il souhaite faire et dans quel cas on doit/peut l'utiliser ? Tu parles de yes-classes
Citation:
Envoyé par PauseKawa

Code:

1 2 3 4 5 6 myobj = PassePartout() if len(myobj): for e in myobj: print(e) for e in myobj: print(e)
2 fois les même lignes, on peut pas faire mieux?
Citation:
Envoyé par PauseKawa

Code:

1 2 3 4 5 6 7 8 9 10 11 12 def __len__(self): return 0 len = __len__ def __next__(self): raise StopIteration next = __next__ def __iter__(self): return self
Euh, j'ai un peu de mal là :oops:

len = __len__ est-ce utile?

Si len(objet) donne toujours 0

pourquoi cette condition?

Code:

if len(myobj):

:oops:

J'étais à fond sur le

Code:

1
2
3
4
    def __next__(self):
        raise StopIteration
 
    next = __next__

Cela reviens donc à:

Code:

1
2
3
4
5
6
7
8
9
10
    def __len__(self):
        return 0
 
    def __next__(self):
        raise StopIteration
 
    next = __next__
 
    def __iter__(self):
        return self

(next = __next__ pour 2.X/3.X)

26/12/2011, 20h48
fred1599
D'accord mais PassePartout concrètement représente quoi comme objet?

Car admettons que se soit une yes-classe, ok, il me faut un argument pour dire que je laisse passer tel objet (toujours sur le principe du proxy).
Code:

1 2 3 class PassePartout(object): def __init__(self, objet): self.objet = objet
En plus ce genre de ligne

Code:

def __getitem__(self,key): return PassePartout()

Berk!
Code:

1 2 3 4 5 6 def __getitem__(self, key): if isinstance(objet, dict): if key not in self.objet: return 1 else: return self.objet[key]
Enfin bref le PO ne respecte pas la PEP 8 comme tu le soulignes le post précédent, mais en plus les concepts de la POO.

On ne peut pas faire de POO sur des objets inconnus, étant donné qu'une classe est le patron d'un objet.

On pourrait parler de tunnel, mais là encore le contrôle des objets doit être précis, et bien plus complexe que de simples pass.
26/12/2011, 20h52
PauseKawa

Citation:

Envoyé par PauseKawa

Si c'est vraiment pour faire de l'universel je trouve cela dangereux.
26/12/2011, 20h58
fred1599

Citation:

Si c'est vraiment pour faire de l'universel je trouve cela dangereux

On est d'accord, depuis le début d'ailleurs et ton premier post résume tout ce que je pense.

Le POO doit être plus précis dans le type d'objet et à la rigueur si c'est un objet connu on pourrait tout simplement en dériver et rajouter des méthodes.

Enfin c'est open bar, on peut rentrer dans des scénarios sans limite de pensée.
26/12/2011, 21h15
PauseKawa

Citation:

Envoyé par PauseKawa

En Python le programmeur est considéré comme responsable et dans ce sens il lui est donné un grande liberté de tester, même dans des cas bien spéciaux de la machinerie interne: perso j'adore cela.
Je classerais donc cela dans la case expérimental.

Citation:

Enfin c'est open bar, on peut rentrer dans des scénarios sans limite de pensée.

Oui, c'est open code. Pourquoi ne pas jouer avec ;)
26/12/2011, 21h33
fred1599

Citation:

Oui, c'est open code. Pourquoi ne pas jouer avec

Oui, alors quel scénario tu proposes? Entrées? Sorties? Types d'objet? itérable?

;)

Citation:

Envoyé par VV33D

Pour ma part, il devrait y avoir un scindage:
- Un proxy:

Citation:

une petite classe dont le but est d’être utilisée comme proxy de n'importe quoi.

- un foure-tout:

Citation:

ne pas lever d'erreur lorsqu'elle est utilisée à la place de l'objet attendu

Les proxys etants déjà Built-In, il reste plus qu'à faire le foure-tout.

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
class PassePartout:
    """Universal Proxy Object"""
    _exemple= None
    __class__ = object
    def __init__(self, *args, **kw):    #s'il passe partout, il doit pouvoir tout gober!
        self._nextCount = False
        pass
 
    def __getattr__(self,key):
        if key== "__str__": return "PassePartout"
        if key== "__repr__": return "PassePartout"
        return PassePartout()   #Dans le fond, c'est plutôt bien pensé
 
    def __setattr__(self,key,value):
        pass
 
    def __getitem__(self,key):
        return PassePartout()   #Pareil que plus haut.
 
    def __setitem__(self,key,value):
        pass
 
    def __str__(self):return "PassePartout"
 
    def __repr__(self):return "PassePartout"
 
    def __hash__(self):
        """same hashcode for every instance"""
        if PassePartout._exemple is None:
            PassePartout._exemple= PassePartout()
        return object.__hash__(PassePartout._exemple)
 
    def __call__(self,*args,**kwargs): return PassePartout()
 
    def __nonzero__(self,*args,**kwargs): return True
 
    def __coerce__(self,other):
        this= None
        if other.__class__== float(1.0).__class__: this= 0.0
        if other.__class__== int(1).__class__: this= 0
        return (this,other)
 
    def __len__(self):
        return 1
 
    len = __len__
 
    def __next__(self):
            raise StopIteration
 
    next = __next__
 
    def __iter__(self):
        return iter((self,))
 
    def __instancecheck__(self, instance):
        print "check instance"       #je parviens pas à le faire rouler (py2.7)
        return True
 
    def __subclasscheck__(self, subclass):
        print "check class"    #Lui non plus
        return True

27/12/2011, 07h14
PauseKawa
Bonjour afranck64,

Pourquoi
Code:

1 2 def __len__(self): return 1
et
Code:

1 2 def __iter__(self): return iter((self,))
Plutôt que
Code:

1 2 def __len__(self): return 0
Code:

1 2 def __iter__(self): return self
?

@fred1599: Et bien puisque les deux questions qui se sont posées d'elles mêmes sont l'itérable et le fait que l'objet retourné ne correspond pas autant commencer par là, non ?

@+
27/12/2011, 16h08
afranck64

@PauseKawa vu que l'objet se doit de retourner du "passe-partout" sous 360°.
Avec le __iter__:return self, un list(passe_p) produit une liste vide. (on perd en "passabilité-partout" :aie: )
29/12/2011, 20h39
shaiHulud

Bonjour,

Tout d'abord, merci à tous pour vos remarques !

* Désolé pour l'erreur de vocabulaire. Ce n'est pas un proxy de quelque chose, c'est plutôt un "substituable universel" ("Fourre tout" me fait trop penser à un conteneur)

* Le cas d'utilisation qui me semble idéal, ce sont deux classes couplées A et B. Dans mon cas, il s'agissait d'un conteneur B (contenant des A) qui s'organise dynamiquement à chaque fois qu'un des attributs d'un de ses éléments est modifié. Le code étant couplé, il était difficile de créer des A() pour faire des tests sans une instance de B. Pour m'en passer, j'ai fait croire à mes instances de A qu'elles étaient contenues dans un passe partout.

* _ exemple me sert uniquement de hashcode unique. A partir du moment ou l'objet ne contient rien d'intéressant et ne garantit pas la justesse de ce qu'il "renvoie", autant gagner de la mémoire dans les dict ou il apparait.

* Je vous accorde qu'il est plus naturel de renvoyer self, mais j'ai eu besoin de renvoyer une nouvelle instance pour des boucles (infinies sinon) qui testent l'égalité entre un PassePartout et ce qu'une de ses méthode renvoie. Comme j'imagine aisément des codes qui planteraient dans le cas inverse, il faut rendre ce comportement paramétrable. Idem pour l'itération infinie.

* Merci pour les tests d'instance, j'avais oublié.

*

Citation:

vu que l'objet se doit de retourner du "passe-partout" sous 360°.
Avec le __iter__:return self, un list(passe_p) produit une liste vide. (on perd en "passabilité-partout" )

Bonne idées, mais je ne suis pas certain, à cause de codes qui itérerait jointement (zip par exemple) sur une liste de passepartout, et une liste de fonctions de ceux ci. Je n'en ai pas eu besoin en tout cas. Eventuellement un autre comportement paramétrable
29/12/2011, 21h09
PauseKawa

Bonsoir VV33D,

Bien content de ton retour pour répondre à nos interrogations ;)

Citation:

Envoyé par VV33D

* Désolé pour l'erreur de vocabulaire. Ce n'est pas un proxy de quelque chose, c'est plutôt un "substituable universel" ("Fourre tout" me fait trop penser à un conteneur)

* Le cas d'utilisation qui me semble idéal, ce sont deux classes couplées A et B. Dans mon cas, il s'agissait d'un conteneur B (contenant des A) qui s'organise dynamiquement à chaque fois qu'un des attributs d'un de ses éléments est modifié. Le code étant couplé, il était difficile de créer des A() pour faire des tests sans une instance de B. Pour m'en passer, j'ai fait croire à mes instances de A qu'elles étaient contenues dans un passe partout.

J'ai besoin d'un exemple là... Merci d'avance ;)

@+

Code:

1 2 3 4 5 6 7 8 9 10 11 12 class A(dict): """ La classe A a besoin d'une instance de B pour fonctionner """ def __init__(conteneur): dict.__init__(self) self.conteneur=conteneur def __setitem__(self,k,v): self.conteneur.notify_change(self,k,v) dict.__setitem__(self,k,v) class B: pass
Dans mon cas, B maintient pour chaque (key,value) une liste distincte de ses éléments tels que element[key]== value. Mais on peut imaginer ce qu'on veut : une IHM pour interfacer un objet, un réseau ou on envoie l'information... dans tous les cas, le but est de récupérer des instances de A sans créer un B, qui est en général un objet lourd. Mon approche est de remplacer B par un passepartout

29/12/2011, 23h17
PauseKawa

Citation:

deux classes couplées A et B

Et le lien entre A et B ?
Un exemple sur la base du code poster svp ;)
29/12/2011, 23h37
shaiHulud

dans cet exemple, aucun autre lien que :
* la classe A a besoin d'un notifiable (appel explicite dans la code)
* Tous les éléments de ce conteneur notifiable doivent coupler __setitem__ et notify(), de sorte que les listes gérées par notify soient tjs à jour.

il s’avère que dans mon cas réel, les instances de A accèdent également à B ailleurs pour d'autres raisons.

Plus généralement, j'ai une classe voiture qui suppose qu'elle possède un moteur et qui lui envoie des ordres (c'est pas ma faute si elle a été mal conçue).
Je veux tester sans moteur le reste de son comportement (elle croit aussi qu'elle a des pneus, etc), et bien je lui installe un moteur passe partout.

Bref, réutiliser du code mal conçu (trop couplé?), en ayant le moins d'accident de voiture possible

Un exemple est déjà plus parlant pour moi, si j'ai bien compris tu souhaiterais un truc de ce genre?
Code:

1 2 3 4 5 6 7 8 9 10 11 class Moteur(object): def __init__(self): print "Moteur initialise" class Voiture(Moteur): def __init__(self, control_moteur=True): self.control = control_moteur if self.control == True: Moteur.__init__(self) v = Voiture(control_moteur=False)
Edit : C'est une relation d'agrégation ou de composition

Ce n'est pas ce que je souhaite, c'est ce que j'ai : je dispose d'un agrégat, mais il n'a pas été prévu pour gérer l'absence de ses composants (il n'y a pas le test if self.control == True: Moteur.__init__(self) ).

Pour découpler ces composants, il faudrait effectivement rajouter ce genre de if. Il faut malheureusement le faire à beaucoup d'endroits, ce qui demande de retoucher le code, donc du temps.

Ce que je souhaite, c'est tester les autres composants de la voiture sans avoir à réécrire son code pour découpler ses composants.
Code:

1 2 3 4 5 6 7 8 9 10 11 class moteur: def __init__(self,voiture): self.voiture= voiture def accelerer(self): self.voiture.roues.tourner() class voiture: def __init__(self): self.moteur= moteur(self) self.roues= roues(self)

30/12/2011, 15h12
fred1599
Citation:

Pour découpler ces composants, il faudrait effectivement rajouter ce genre de if. Il faut malheureusement le faire à beaucoup d'endroits, ce qui demande de retoucher le code, donc du temps.

avec une boucle for?
Code:

1 2 3 liste_objets = [Moteur, Roues, ...] for objet in liste_objets : objet.__init__(self)
Ce qui ne fait plus beaucoup de modifications finalement, à moins que je n'ai pas tout compris.
30/12/2011, 17h31
shaiHulud

Citation:

avec une boucle for?

Non, car il faudrait rajouter ce if (qu'il soit dans une boucle ou non) dans toutes les fonctions qui essayent d'utiliser self.moteur. Le problème ne se pose pas uniquement à l'init (par exemple la méthode accélerer dans mon exemple)
30/12/2011, 22h27
fred1599

J'avoue être perdu, je ne vois pas la difficulté, sinon peut-être dû à un problème de conception du code dont tu parles, je sais pas?

Sinon le plus simple serait de montrer le code en question afin d'en discuter plus clairement.

Fuseau horaire GMT +2. Il est actuellement 09h49.