la bonne manière de vérifier le type d'un objet ?

Recherche :

Mot : Pseudo : Filtrer
Bas de page
Auteur	Sujet : la bonne manière de vérifier le type d'un objet ?

psychotek

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) :

Code :

class MaListe(UserList):
def __init__(self):
UserList.__init__(self)
def append(self, o):
if not o.__class__.__name__ == "MaClasse": raise TypeError
UserList.append(self, o)

Merci.

Message cité 1 fois

Publicité

multani

Dépressionnisé

type ou isinstance sont mieux je pense ...

http://www.python.org/doc/current/ [...] funcs.html

masklinn

í dag viðrar vel til loftárása

psychotek a écrit :

Code :

class MaListe(UserList):
def __init__(self):
UserList.__init__(self)
def append(self, o):
if not o.__class__.__name__ == "MaClasse": raise TypeError
UserList.append(self, o)

Merci.

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

Message cité 1 fois
Message édité par masklinn le 20-12-2005 à 17:07:07

---------------
I mean, true, a cancer will probably destroy its host organism. But what about the cells whose mutations allow them to think outside the box by throwing away the limits imposed by overbearing genetic regulations? Isn't that a good thing?

multani

Dépressionnisé

masklinn a écrit :

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).

Spour ça que j'ai mis isinstance aussi [:cupra]

Sinon, c'est "trai trai mal" pourquoi, comment, etc. ? [:opus dei]

masklinn

í dag viðrar vel til loftárása

C'est malpratique et peu flexible

Mais surtout, type() ne gère pas l'héritage alors que isinstance si:

Code :

>>> 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
>>>

Profil supprimé

masklinn tu viens de montrer que "type" était indispensable au lieu de montrer qu'il était à proscrire, là. :gratgrat:

On peut vouloir connaître le type exact d'un objet indépendamment de son héritage et donc "isinstance" ne suffit pas.

Message cité 1 fois

masklinn

í dag viðrar vel til loftárása

Je crois que t'as pas tout pigé au bouzin [:pingouino]

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 [:pingouino]

Il n'y a aucun avantage à utiliser type, si t'en trouve un je veux un use case concret [:itm]

Mr Mala

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() ???

Message cité 1 fois

masklinn

í dag viðrar vel til loftárása

Mr Mala a écrit :

Et qu'est-ce que ça pourrait lui apporter?

Mais bon, à part ça je reste sur ma position définie en tant que:

Citation :

La meilleure manière de le faire, c'est de pas le faire.

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

Message édité par masklinn le 20-12-2005 à 18:47:03

Mr Mala

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 ! [:itm]

Message cité 1 fois
Message édité par Mr Mala le 20-12-2005 à 18:48:14

Publicité

masklinn

í dag viðrar vel til loftárása

Mr Mala a écrit :

PQ il ne pourrait pas ?

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

Code :

>>> 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

Citation :

- Object type comparisons should always use isinstance() instead
of comparing types directly.

Yes: if isinstance(obj, int):

No: if type(obj) is type(1):

Mr Mala

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

psychotek

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

Message cité 1 fois

Taz

bisounours-codeur

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.

masklinn

í dag viðrar vel til loftárása

psychotek a écrit :

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 ?

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?

psychotek a écrit :

question subsidiaire à propos de List et UserList : il faut éviter d'utiliser UserList mais on peut utiliser UserDict ?

Non [:el g]

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)

psychotek

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 ?

Message cité 1 fois

masklinn

í dag viðrar vel til loftárása

psychotek a écrit :

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.

Ben tu te plantes [:spamafote]

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.

psychotek a écrit :

typage dynamique n'est pas synonyme d'absence de typage. qu'en pensez-vous ?

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.

Message édité par masklinn le 21-12-2005 à 13:43:55

Taz

bisounours-codeur

issu de ruby ... mouahahahah

Message cité 1 fois

masklinn

í dag viðrar vel til loftárása

Taz a écrit :

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.

Taz

bisounours-codeur

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

Message cité 1 fois

masklinn

í dag viðrar vel til loftárása

Taz a écrit :

ah bah si t'es du genre 'c'est le premier qui nomme qui gagne' ...

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

Taz a écrit :

si tu veux pousser loin, tu prends boo, ou duck est carrément un mot-clef

Wait, no one cares

Publicité

FORUM HardWare.fr

Programmation

Python

la bonne manière de vérifier le type d'un objet ?

Sujets relatifs
[XSchema] restrictions sur type string	A la recherce d'un Portail de type PHP Nuke...
Afficher le nom d'un type.	Fichier EF ANR type 2 / Carte SIM-GSM
Objet sound() dans un clip chargé par loadClip	formulaire de type file et le chemin complet
[Delphi / Exception] création de type d'exception particulier	[C#, Winforms] Passage d'un contrôle de type 'Form' en paramètre.
Type non reconnu	Besoin d'aide sur setInterval et javascript orienté objet...
Plus de sujets relatifs à : la bonne manière de vérifier le type d'un objet ?

Page générée en 0.068 secondes