Bonjour,
 
Je cherche à vérifier qu'un objet est du bon type avant de l'ajouter à une liste ; s'il ne l'est pas, on lève une exception. Quelle est la bonne manière de faire cela ? Je préssent qu'il faut utiliser __class__ mais j'ai cherché un peu et je n'arrive pas à trouver.
 
Voici la "mauvaise manière" (enfin je pense) :

 
Merci.

type ou isinstance sont mieux je pense ...
 
http://www.python.org/doc/current/ [...] funcs.html

La meilleure manière de le faire, c'est de pas le faire.
 
Sinon, isinstance (multani > type est considéré "trai trai mal" sur les ng python:o).
 
Et accessoirement, ça fait depuis Python 2.2 qu'on hérite plus de User*, dégage moi ce UserList et remplace le par "list" si tu es sur un interpréteur 2.2, 2.3 ou 2.4 merssi
 
Et un message utilisable pour l'erreur ça serait pas du luxe

Spour ça que j'ai mis isinstance aussi
 
Sinon, c'est "trai trai mal" pourquoi, comment, etc. ?

C'est malpratique et peu flexible
 
Mais surtout, type() ne gère pas l'héritage alors que isinstance si:

>>> class MyClass(object):
    def __init__(self):
        pass
 
    
>>> a = MyClass()
>>> type(a) == MyClass
True
>>> type(a) == object
False
>>> isinstance(a, MyClass)
True
>>> isinstance(a, object)
True
>>>

masklinn tu viens de montrer que "type" était indispensable au lieu de montrer qu'il était à proscrire, là.
 
On peut vouloir connaître le type exact d'un objet indépendamment de son héritage et donc "isinstance" ne suffit pas.

Je crois que t'as pas tout pigé au bouzin
 
L'intérêt d'isinstance c'est qu'il "sait" que notre objet est compatible avec toutes les classes dont il hérite, directement ou indirectement, type ne le sait pas.
 
Mais dans mon exemple, si je teste un machin instancé depuis "object" pour savoir si c'est une instance de "MyClass", je vais me faire jeter
 
Il n'y a aucun avantage à utiliser type, si t'en trouve un je veux un use case concret

Ben .. ce serait possible une explication plus "concrète" dans le cas présent proposé par l'auteur ?
Je cite "Je cherche à vérifier qu'un objet est du bon type avant de l'ajouter à une liste" ...  
Voilà; il veut uniquement les objets disons de type MyClass .. rien d'autre et pas un type hérité .. juste celui-là ...
Qu'est-ce qui l'empêche d'utiliser simplement type() ???

Et qu'est-ce que ça pourrait lui apporter?
 
Mais bon, à part ça je reste sur ma position définie en tant que:

 
cf http://www.canonical.org/~kragen/isinstance/ pour plus d'infos

Qu'est-ce que je sais moi, je pose la question, stou !
if type(o) == MyClass :
pis basta, c'est tout puisque c'est spécifiquement CA qu'il veut ...
PQ il ne pourrait pas ?
 
Je pourrais te dire exactement la même chose que toi:
ICI, il n'y a aucun avantage à utiliser isinstance, si t'en trouve un je veux un [..] une explication concrète, je répète, dans le cas présent !

• il arrive à type() de bugger, ou de demander l'utilisation du modules types

>>> import UserDict
>>> type(UserDict.UserDict()) == UserDict.UserDict
False
>>> isinstance(UserDict.UserDict(), UserDict.UserDict)
True

• Dans la PEP 8, Guido demande explicitement d'utiliser isinstance et non type

Et ben VOILA ! ... CA, c'est une explication/raison claire et précise !!! ...

j'ai beaucoup appris dans ce post, merci à tous.
 
cependant masklinn, pourquoi dis-tu qu'il serait préférable de ne pas le faire ? étant donné qu'on a pas de templates et autres cochoneries de ce genre, comment m'assurer que les éléments de ma liste sont du bon type ?
 
question subsidiaire à propos de List et UserList : il faut éviter d'utiliser UserList mais on peut utiliser UserDict ?
 
merci

UserList c'est complètement déprécié. Dérive list directement. Pareil pour dict.
 
Et puis on est en python, évite de faire de la parano au niveau du typage statique.

La question est:
 
Pourquoi donc veux tu des éléments d'un type précis? que veux tu faire avec tes machins? et quel est le risque de mettre des éléments d'un "mauvais" type dans la liste de toute façon?

Non  
 
Python 2.2 new style classes & unification types & classes:

• Tout objet doit directement ou indirectement hériter d'object
• Toutes les classes User* sont dépréciées (sauf nécessité de compatibilité avec Python 2.1 et plus ancien), on peut hériter directement des types standards (list, dict, int, long, set, frozenset, tuple, complex, etc etc)

bon, j'ai encore appris plein des choses, je ne viens pas pour rien
 
concernant la vérification de type, c'est vrai que c'est du python, mais un minimum de vérification ne fait pas mal d'après moi. avoir des listes contenant des objets d'un même type fait partie de ce minimum, d'après moi.
 
disons que je place dans ma liste des objets, avec une archi un peu compliquée et des imbrications de listes dans des listes, et faire ces vérifications de types m'évitent de me planter et de débugger après. l'inférence de type est de l'aide au programmeur, après tout.
 
en fait, bien que dynamique, le système de type pourrait proposer deux types de listes : des listes homogènes et des listes hétérogènes. typage dynamique n'est pas synonyme d'absence de typage. qu'en pensez-vous ?

Ben tu te plantes  
 
Vas lire le truc que j'ai posté un peu plus haut sur le sujet, et renseigne toi sur le concept de duck typing (issu de ruby), puis sur le concept de tests unitaires et leur intérêt.

J'en pense que je vois pas le rapport, Python est un langage à typage dynamique fort, c'est pas pour ça que passer par isinstance a un intérêt.
 
Là encore, renseigne toi sur le concept de duck typing et oublie ce que tu a appris en faisant du java, Python is not Java toussa.

issu de ruby ... mouahahahah

Le concept est (partiellement) issu des langages à typage dynamique précédents (smalltalk), mais le nom "duck typing" et la formalisation exacte du concept viennent de Dave Thomas sur la ml ruby-talk.
 
Son message d'explication est ici, pas trouvé la première occurence de l'expression.

ah bah si t'es du genre 'c'est le premier qui nomme qui gagne' ...
 
si tu veux pousser loin, tu prends boo, ou duck est carrément un mot-clef

Non, contre je suis pas mal du genre "le premier à formaliser un concept", oui

Wait, no one cares