Discussion :

[Sve@r]

Bonjour

Je voudrais qu'on me parle de __cmp__ sous P3. J'avais implémenté dans un objet P2 la méthode __cmp__ qui me permettait de les comparer. Or déjà ça ne fonctionne plus sous P3 et sur le net c'est dit que ce n'est plus supporté.
Je trouvais pourtant assez pratique d'implémenter en une seule fonction toute la gamme des possibilités "<", "<=", "==", "!=", ">", ">=". Maintenant je vais devoir rajouter dans mes algos dans les méthodes "__lt__" et ses consoeurs.

Par exemple pour comparer 2 dates, voici mon approche

Code python :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
class date(object):
	def __init__(self, jj, mm, aa):
		self.__jj=jj
		self.__mm=mm
		self.__aa=aa
	def __cmp__(self, other):
		if (self.__aa < other.__aa): return -1
		if (self.__aa > other.__aa): return 1
		if (self.__mm < other.__mm): return -1
		if (self.__mm > other.__mm): return 1
		if (self.__jj < other.__jj): return -1
		if (self.__jj > other.__jj): return 1
		return 0

Pratique sous P2. Maintenant je vais devoir à minima rajouter def __lt__(self, other): return date.__cmp__(self, other) < 0 sous P3 pour que ça fonctionne (et pareil avec tous les autres opérateurs).

Quelqu'un aurait-il la raison de cette suppression ? Peut-être que ma façon d'aborder la comparaison de deux objets n'est pas bonne.

Merci à tous

[wiztricks]

Salut,

Quelqu'un aurait-il la raison de cette suppression ? Peut-être que ma façon d'aborder la comparaison de deux objets n'est pas bonne.

La lecture du PEP 207 devrait répondre à la question.

- W

[Sve@r]

La lecture du PEP 207 devrait répondre à la question.

C'est pas évident de comprendre (en plus moi et l'anglais...)
Ca parle de comparaison stricte et de comparaison riche (par exemple a-t-on le droit de voir a!= b comme étant implicitement "non (a == b)"
D'après ce que je lis, P2 partait de l'hypothèse que a != b devait être automatiquement vu comme "non (a == b)" (et idem avec les autres opérateurs complémentaires les uns avec les autres). __cmp__ permettait alors de créer cette équivalence.
Dans P3 cette équivalence ne serait plus implicite et devrait alors être spécifiée.

Toutefois, ce second exemple fonctionne en P2 et aussi en P3 et dans les deux cas, implémente une équivalence implicite entre les opérateurs et leur opposé respectif.

Code python :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
class date(object):
	def __init__(self, jj, mm, aa):
		self.__jj=jj
		self.__mm=mm
		self.__aa=aa
	def __lt__(self, other):
		print("lt: ", self, other)
		if (self.__aa < other.__aa): return True
		if (self.__mm < other.__mm): return True
		if (self.__jj < other.__jj): return True
		return False
 
a=date(15, 11, 2020)
b=date(1, 12, 2020)
print(b > a)

Non seulement il donne le bon résultat mais en plus je vois la trace de "lt" qui est appelée. Il a bien considéré ">" comme un "non <". Et idem si j'implémente "__le__" et que je demande un test ">=". Et idem si je remplace "__le__" par "__ge__" et "__lt__" par "__gt__". L'opérateur qui n'est pas implémenté est alors traduit comme la négation de son homologue.
Bref ça devient de plus en plus confus.

[edit] Ok, j'ai vu d'autres docs en français et je commence à comprendre. C'est pour éliminer le conflit entre "faut-il utiliser le not d'un opérateur existant pour avoir son inverse ou faut-il utiliser __cmp__". Donc plus de "__cmp__", plus de question métaphysique.
J'espère avoir trouvé la réponse.