Discussion :

[N.tox]

@kango: n'est-ce pas là embrouiller davantage quelqu'un qui débute ? K.I.S.S*
Qui plus est, et ce n'est là que mon point de vue, déduire ce que fait un objet en fonction de ce qu'il est est tout aussi valable que l'inverse, cela dépend des cas.


*:Keep It Simple, Stupid

[kango]

est ce que le fait d'utiliser les idiomes adaptés à un langage constitue une forme d'embrouille ?

lorsque les créateurs du langage Python nous proposent des objects comme:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
for data in obj:
   #fais ce que tu veux

où obj peut être énormément de choses (chaine, liste, dictionnaire, fichier...), sans que l'on ait à déterminer le type de obj, penses tu qu'ils cherchent à embrouiller les débutants ou au contraire à les aider ?

la réponse me semble assez évidente

[N.tox]

Je suis probablement très couillon, mais je ne vois pas le rapport

Edit : je crois qu'il y a quiproquo, mon point n'était pas de contester l'approche que tu préconise, mais plutôt de dire que c'est une information de plus, et qu'il vaut mieux bien retenir une information, que peu plusieurs... mais qu'importe, j'aurais probablement mieux fait de me taire. Aucun ressentiments, soyons clair.

[kango]

mais qu'importe, j'aurais probablement mieux fait de me taire.

pas du tout le débat est constructif. on a le droit de ne pas être d'accord

mes excuses si mon message est apparu péremptoire, je cherchais uniquement à évoquer un sentiment personnel.

mon point de vue est que isinstance ou type sont deux approches qui masquent la philosophie de Python derrière. je comprends que ce puisse être tentant de l'utiliser.

[dividee]

Bonjour,

proposer isinstance ou type dans un langage à typage dynamique pour résoudre ce genre de problème me semble ne pas être une bonne habitude de programmation

Ben c'est justement le typage dynamique qui permet de faire ce genre de chose. Dans un langage à typage purement statique, ce n'est de toute façon pas possible (le fait que ce soit possible en Java, en passant par la réflexion, ajoute justement un côté dynamique au langage).

Je ferais une distinction entre type et isinstance; le second me semble nettement préférable car il respecte le principe fondamental de l'héritage (principe de substitution: si B hérite de A, une instance de B peut toujours être utilisée lorsqu'un instance de A est requise). type casse ce principe et me semble donc beaucoup plus dangereux.

ce qui est important en Python, ce n'est pas ce que les choses sont, mais ce que les choses font (le fameux duck typing de Python).

quelles sont les méthodes de ElementaryCell et de ComplexCell que tu veux utiliser dans ton traitement ? ou question posé différemment , comment peux tu distinguer une ElementaryCell d'une ComplexCell en fonction de leurs méthodes ?

Si je comprends bien, tu suggères d'utiliser un appel de méthode dans un try/except AttributeError, ou d'utiliser hasattr ? En fait tu es parti dans la direction opposée de celle à laquelle je pensais après ta première phrase
Je suis d'accord sur le fait d'utiliser les idiomes adaptés au langage, mais pour moi isinstance en est un. Et je ne suis pas persuadé que la philosophie derrière le duck typing soit de pousser à l'utilisation de hasattr.

Pour moi le duck typing c'est plutôt ceci:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
class A(object):
    ...
    def traitement(self):
        # traitement A
 
class B(object):
    ...
    def traitement(self):
        # traitement B
 
def traitement(x):
    return x.traitement()

Cela exploite aussi le duck typing (car A et B n'ont pas à implémenter une interface commune). Le défaut est que le code du traitement est réparti dans les différentes classes, à voir si c'est judicieux ou pas en fonction du cas.

Sinon, on peut aller plus loin et implémenter le "visitor pattern", mais c'est un peu l'inverse de la programmation "idiomatique":

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
class A(object):
    ...
    def accept(self, visitor):
        # peut contenir des appels à accept sur les composants de self
        visitor.visit_A(self)
 
class B(object):
    ...
    def accept(self, visitor):
        # peut contenir des appels à accept sur les composants de self
        visitor.visit_B(self)
 
class TraitementVisitor(object):
    ...
    def visit_A(self, obj):
        # traitement A
 
    def visit_B(self, obj):
        # traitement B
 
def traitement(x):
    x.accept(TraitementVisitor())

Le souci, c'est que, vu de Python, cela ressemble à une tentative verbeuse de se passer de isinstance: le mécanisme est essentiellement le même, mais utilise implicitement le dynamic dispatch au lieu d'appels explicites à isinstance.

[kango]

salut dividee,

oui tout à fait, ma vision du duck typing correspond à celle que tu mentionnes.

non je ne fais pas allusion à hasattr, même si je le préfère à isinstance dans le sens où il interroge l'interface plutôt que l'implémentation.

je faisais plutôt allusion au try / except ou tout simplement à l'interface commune que pourrait peut être avoir ComplexCell et ElementaryCell. C'est pour cela que je demandais s'il y a une distinction entre les deux classes relatif au traitement attendu.

si les deux classes possèdent des interfaces différentes, on peut se demander s'il est judicieux de les avoir dans une même collection (ce qui éviterait d'avoir à traiter la distinction par le biais de isinstance).

j'ai en fait beaucoup de mal à croire que isintance soit LA solution au problème initial.

isinstance existe dans le langage Python, certes, mais son utilisation dans la librairie standard Python (qui on peut en convenir, devrait être une référence) est extrêmement marginale.

enfin, par expérience, isinstance fait prendre de mauvaises habitude en ce qui concerne les interfaces. On ne se soucie plus de l'homogénéité des interfaces parce qu'on se dit: "bof de toute façon, je ferais un isinstance..."

programmer pour une interface devrait être privilégié à programmer pour une implémentation (ce n'est pas de moi): je pense que c'est le fondement de la programmation orientée objet.

[N.tox]

mes excuses si mon message est apparu péremptoire, je cherchais uniquement à évoquer un sentiment personnel.

Don't worry, il ne l'était pas. Je continue de croire que j'aurais du m'abstenir de remettre en cause ta démarche pédagogique, c'est tout

isinstance, type, ou hasattr (que je préfère à un exception catching )... tout ça dépend du cas auquel on fait face...

Si on veut s'assurer qu'un objet est bien iterable, un hasattr(obj,'__iter__') est je trouve ce qu'il y a de plus efficace et de plus court.

un exemple justement sur un truc que je me suis mis à taffer hier, où type est incontournable (Box.__init__), en speed : Box est le root nécessaire à la création de tout une arborescence de VBox et HBox (se veux ressembler au même truc dans les GUI, c'est assez moche pour l'instant, mais ce n'est pas la question )

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

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
class Box(object):
    class width_parts(Property):
        def get(s): return s._width_parts
        def set(s,v): s._width_parts = v
    class height_parts(Property):
        def get(s): return s._height_parts
        def set(s,v): s._height_parts = v
    def __init__(s,size=None,pos=None):
        if type(s)==Box:
            s.size  = size
            s.pos   = pos
        s.childs    = []
    def _compute_zone(s):
        wp,hp = [i/float(j) for i,j in zip(s.size,(s.width_parts,s.height_parts))]
        xs=ys = 0
        for child in s.childs:
            xe = xs+int(wp*child.width)
            ye = xs+int(hp*child.height)
            child._zone = (xs,xe),(ys,ye)
            child._size = xe-xs, ye-ys
            xs,ys = xe,ye
 
class VBox(Box):
    class height(Property):
        def get(s)   : return s._height
        def set(s,v) :
            s.parent_box.height_parts -= s._height
            s.parent_box.height_parts += v
            s._height = v
            s.parent_box._compute_zones()
    class width(Property):
        def get(s)   : return 0
    class zone(Property):
        def get(s)   : return s._zone
    class size(Property):
        def get(s)   : return s._size
    def __init__(s,parent_box,height=0):
        Box.__init__(s)
        s.parent_box    = parent_box
        s.height = height
        s.width  = 0
 
class HBox(Box):
    class height(Property):
        def get(s)  : return 0
    class width(Property):
        def get(s)  : return s._width
        def set(s,v):
            s.parent_box.height_parts -= s._height
            s.parent_box.height_parts += v
            s._width = v
            s.parent_box._compute_zones()
    class zone(Property):
        def get(s)   : return s._zone
    class size(Property):
        def get(s)   : return s._size
    def __init__(s,parent_box,width=0):
        Box.__init__(s)
        s.parent_box    = parent_box
        s.height = 0
        s.width  = width

isinstance est extrêmement utile pour savoir si un objet appartient bien à une famille. ex : dans une fonction on à besoin de vérifier qu'un argument est du type X, mais si un dev surclasse la-dite classe, il faut qu'une instance de cette dernière passe le test, donc ici, préférer isinstance, afin d'assurer une compatibilité pour d'éventuelles améliorations futures.

Bref, c'est au cas par cas.

[PauseKawa]

Bonjour,

proposer isinstance ou type dans un langage à typage dynamique pour résoudre ce genre de problème me semble ne pas être une bonne habitude de programmation

En fait si j'avais proposer isinstance, dans ce cas précis,

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
>>> class Cells(object):
...     pass
... 
>>> 
>>> class ElementaryCell(Cells):
...     pass
... 
>>> 
>>> class ComplexCell(Cells):
...     pass
... 
>>> dico = {'cellule1': ElementaryCell(), 'cellule2': ComplexCell()}
>>> for c in dico:
...     if isinstance(dico[c], ComplexCell):
...         print(c)
... 
cellule2

c'est que type ne me semble pas correspondre.
type(object)
Return the type of an object. The return value is a type object. The isinstance() built-in function is recommended for testing the type of an object.
De plus dans l’absence d'information sur ElementaryCell/ComplexCell type peut être source à erreur.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
>>> class A:
...     pass
... 
>>> a = A()
>>> type(a) == A
False
>>> class A(object):
...     pass
... 
>>> a = A()
>>> type(a) == A
True

Je ferais une distinction entre type et isinstance; le second me semble nettement préférable car il respecte le principe fondamental de l'héritage (principe de substitution: si B hérite de A, une instance de B peut toujours être utilisée lorsqu'un instance de A est requise). type casse ce principe et me semble donc beaucoup plus dangereux.

Je vais plus dans ce sens là.

Pour ce qui est de visiter l'objet (hasattr etc) à la recherche d'une méthode, d'un attibut, etc... N'est il pas plus simple d'utiliser __class__ ?

isinstance existe dans le langage Python, certes, mais son utilisation dans la librairie standard Python (qui on peut en convenir, devrait être une référence) est extrêmement marginale.

En vrac:
collections.py

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

    if isinstance(field_names, basestring):

os.py

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
            p = subprocess.Popen(cmd, shell=isinstance(cmd, basestring),
                                 bufsize=bufsize, stdin=PIPE, stdout=PIPE,
                                 close_fds=True)

pickle.py

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

        if not isinstance(args, TupleType):

etc etc etc

@+

Edit

c'est que type ne me semble pas correspondre

A comprendre que je vois plus type pour tester un objet tel que défini dans types.py.

[kango]

Pour ce qui est de visiter l'objet (hasattr etc) à la recherche d'une méthode, d'un attibut, etc... N'est il pas plus simple d'utiliser __class__ ?

salut,

plus simple je ne sais pas. passer par __class__ est dépendent de l'implémentation alors que hasattr ne l'est pas. On peut trouver par exemple deux implémentations différentes proposant la même interface.

Je reprends l'exemple de dividee:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
class A(object):
    def traitement(self):
        pass
 
class B(object):
    def traitement(self):
        pass

L'utilisation dans ce cas de isinstance ou de __class__ n'aura pas beaucoup d'effet. A et B ne possèdent pas de classe de base commune. Pourtant on peut continuer à les utiliser de manière indifférente !

L'héritage permet de mettre en place une certaine forme de polymorphisme. Dans un langage typé dynamiquement comme Python, on a aussi la possibilité de mettre en place un polymorphisme basé sur l'interface sans nécessairement passer par l'héritage.

isinstance et __class__ sont donc trop réducteurs par rapport à toutes ces conceptions possibles.

Je vais prendre un exemple plus concret, tiré de mon expérience personnelle. J'ai eu à faire un programme faisant transiter des fichiers sur le réseau. J'ai voulu supporter indifféramment le protocole FTP et le protocole SFTP. Le premier est pris en charge par la librairie standard de Python, le second par la librairie paramiko.

Problème, les deux classes proposent des interfaces différentes, et j'aurais pu être tenté dans mon programme de tester le type du client (FTP ou SFTP) en utilisant isinstance. J'ai préféré au contraire définir une interface commune à ces deux clients et j'ai crée pour chacun d'eux un wrapper permettant d'implémenter cette interface. Mais deux wrappers sont des classes différentes, tous deux dépendants de la classe sous-jacente (client FTP ou SFTP). Mais comme ils disposent d'une interface commune, je n'ai pas eu à distinguer les cas dans mon programme d'échange de fichier.

Cette architecture est extrêmement souple car si j'avais à implémenter un autre protocole d'échange, il me suffit de wrapper ce même protocole pour lui donner la même interface que les deux autres et je n'ai rien à changer dans mon programme appelant. Là où une approche basée sur la distinction par le biais de isinstance m'aurait forcé à recoder tous les tests (pour ajouter une classe supplémentaire). C'est dans ce sens que je considère que le passage à isinstance peut parfois sembler être la seule possibilité mais qu'en y réfléchissant, une conception différente permet de s'en passer tout en étant plus souple

[PauseKawa]

Bonjour,

J'avais bien compris tout cela mais je trouve que nous sommes bien loin des considérations de kali38

[kango]

oui tout à fait

[dividee]

Désolé kango, je n'avais pas bien compris ce que tu voulais dire. Je suis en gros d'accord avec toi. isinstance est à manier avec parcimonie, mais il peut occasionnellement être utile. En particulier, il peut être utilisé sans dépendre de l'implémentation avec les ABCs du module collections:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
>>> from collections import Iterable
>>> class A(object):
... 	def __iter__():
... 		pass
... 	
>>> isinstance(A(), Iterable)
True

Remarque qu'il n'y a pas besoin de dériver de Iterable.
C'est quand-même plus joli que hashattr(A(), '__iter__'). Et pour un cas plus complexe, comme tester si un objet est une séquence, c'est tout aussi facile.

Les ABCs en général peuvent servir à fournir une version Python de la notion d'interface, et de par les méthodes register et __subclasshook__ elles peuvent être utilisées de façon très souple.

[kango]

Désolé kango, je n'avais pas bien compris ce que tu voulais dire.

y a pas de mal, je pense de toute façon pas avoir été très clair au début

[brachior]

Je suis aussi d'accord avec kango sur le fait qu'il semble y avoir un certain illogisme à rassembler dans une même collection des entités diamétralement opposées Oo

Sinon, ça n'a aucun rapport mais je pose la question quand même ^^

Pourquoi vous imposez deux recherche dans le dictionnaire
(même si le recherche est supposée en temps constant ^^)

Vous écrivez :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
 
for element in dico:
  if isinstance(dico[elem], Personne):
    ...

Au lieu de :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
 
for key, elt in dico.items():
  if isinstance(elt, Personne):
    ...

( Il y a peu être une raison à ça ^^
Mais j'aimerai l'explication si possible )

[airod]

humm ca s'applique au gens

ce qui est important , ce n'est pas ce que les gens sont, mais ce que les gens font.

[PauseKawa]

( Il y a peu être une raison à ça ^^
Mais j'aimerai l'explication si possible )

Pas vraiment
Le seul point favorable pour moi c'est qu'il n'y a pas de copie du dico.
Maintenant dico[elem] parcourt il vraiment le dico ?

[brachior]

dico[elem] ne parcours pas le dico (c'est une table de hashage)
Mais de faire :

for elem in dico:

C'est un itérateur (générateur) sur le dictionnaire,
Donc on le parcours déjà une fois de toute manière Oo

[PauseKawa]

Bonsoir,

Vous écrivez :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
 
for element in dico:
    if isinstance(dico[elem], Personne):
    ...

Pas compris (Canard boiteux ).
Si for element in dico: parcourt le dico une fois (for > parcourir les objets étirables > .__iter__ : On est ok.) et pas dico[elem] (Ok aussi) ou sont les deux parcours ?

for key, elt in dico.items(): items() retourne des listes qui sont des copies de key, value. Donc une copie du dico sous forme de listes.

Dans l'attente de savoir pour cette histoire de deux parcours je trouve préférable de travailler sur le dico lui même et pas sur une copie non ?

Dans l'attente de votre réponse

[brachior]

Y a eut un abus de langage ^^

Je parlais au début de recherche

Pourquoi vous imposez deux recherche dans le dictionnaire

avec les fautes en prime ^^

Et oui j'avais lu un article où justement ils parlaient d'avoir des références au lieu d'une copie en rapport avec le Framework Java ...
Même il semblerait (à la lecture de la doc actuelle de python 2.7) que ce n'est pas encore fait ^^

Je m'en excuse ^^

Par ailleurs dans la doc ils parlent de recopie sous forme de liste ...
J'espère qu'ils utilisent réellement des générateurs Oo

[PauseKawa]

Je m'en excuse ^^

Ou pas. A voir l'avis des pros.