Bien qu'ayant fait le ménage il y a un certain temps, il restait, dans
de vieilles routines, quelques ... == None (ou ... != None).
Avec Python 2.5, ça passait encore.
Avec Python 2.6 (et certainement avec 3), ça accroche beaucoup plus
souvent. Mais pas toujours...
Pensez à bien utiliser is None
Bien qu'ayant fait le ménage il y a un certain temps, il restait, dans de vieilles routines, quelques ... == None (ou ... != None).
Avec Python 2.5, ça passait encore. Avec Python 2.6 (et certainement avec 3), ça accroche beaucoup plus souvent. Mais pas toujours... Pensez à bien utiliser is None
@-salutations
Et ça fait quoi si on garde l'écriture == None ?
Nicolas
Méta-MCI (MVP) a écrit :
Bonjour !
Bien qu'ayant fait le ménage il y a un certain temps, il restait, dans
de vieilles routines, quelques ... == None (ou ... != None).
Avec Python 2.5, ça passait encore.
Avec Python 2.6 (et certainement avec 3), ça accroche beaucoup plus
souvent. Mais pas toujours...
Pensez à bien utiliser is None
Bien qu'ayant fait le ménage il y a un certain temps, il restait, dans de vieilles routines, quelques ... == None (ou ... != None).
Avec Python 2.5, ça passait encore. Avec Python 2.6 (et certainement avec 3), ça accroche beaucoup plus souvent. Mais pas toujours... Pensez à bien utiliser is None
@-salutations
Et ça fait quoi si on garde l'écriture == None ?
Nicolas
Christophe
NicolasP a écrit :
Méta-MCI (MVP) a écrit :
Bonjour !
Bien qu'ayant fait le ménage il y a un certain temps, il restait, dans de vieilles routines, quelques ... == None (ou ... != None).
Avec Python 2.5, ça passait encore. Avec Python 2.6 (et certainement avec 3), ça accroche beaucoup plus souvent. Mais pas toujours... Pensez à bien utiliser is None
@-salutations
Et ça fait quoi si on garde l'écriture == None ?
Perte des cheveux et départ de la femme aimée.
Accessoirement, c'est bien plus lent que d'utiliser is qui lui est garantit à 100% d'avoir le bon résultat dans des programmes sains d'esprits[1] (pour la comparaison à None), et votre code ne cassera pas dans les versions futures de Python ou l'on changeras le comportement des comparaisons entre objets de types différents.
[1] Les seuls cas dans les versions actuelles ou "a == None" ne renvoie pas le même résultat que "a is None" c'est si a est un objet étrange et pervers qui a surchargé l'opérateur == pour se considérer comme == à None. Ce n'est pas forcément à éviter mais ça doit surprendre ceux qui ne s'y attendent pas j'en suis sur :)
NicolasP a écrit :
Méta-MCI (MVP) a écrit :
Bonjour !
Bien qu'ayant fait le ménage il y a un certain temps, il restait, dans
de vieilles routines, quelques ... == None (ou ... != None).
Avec Python 2.5, ça passait encore.
Avec Python 2.6 (et certainement avec 3), ça accroche beaucoup plus
souvent. Mais pas toujours...
Pensez à bien utiliser is None
@-salutations
Et ça fait quoi si on garde l'écriture == None ?
Perte des cheveux et départ de la femme aimée.
Accessoirement, c'est bien plus lent que d'utiliser is qui lui est
garantit à 100% d'avoir le bon résultat dans des programmes sains
d'esprits[1] (pour la comparaison à None), et votre code ne cassera pas
dans les versions futures de Python ou l'on changeras le comportement
des comparaisons entre objets de types différents.
[1] Les seuls cas dans les versions actuelles ou "a == None" ne renvoie
pas le même résultat que "a is None" c'est si a est un objet étrange et
pervers qui a surchargé l'opérateur == pour se considérer comme == à
None. Ce n'est pas forcément à éviter mais ça doit surprendre ceux qui
ne s'y attendent pas j'en suis sur :)
Bien qu'ayant fait le ménage il y a un certain temps, il restait, dans de vieilles routines, quelques ... == None (ou ... != None).
Avec Python 2.5, ça passait encore. Avec Python 2.6 (et certainement avec 3), ça accroche beaucoup plus souvent. Mais pas toujours... Pensez à bien utiliser is None
@-salutations
Et ça fait quoi si on garde l'écriture == None ?
Perte des cheveux et départ de la femme aimée.
Accessoirement, c'est bien plus lent que d'utiliser is qui lui est garantit à 100% d'avoir le bon résultat dans des programmes sains d'esprits[1] (pour la comparaison à None), et votre code ne cassera pas dans les versions futures de Python ou l'on changeras le comportement des comparaisons entre objets de types différents.
[1] Les seuls cas dans les versions actuelles ou "a == None" ne renvoie pas le même résultat que "a is None" c'est si a est un objet étrange et pervers qui a surchargé l'opérateur == pour se considérer comme == à None. Ce n'est pas forcément à éviter mais ça doit surprendre ceux qui ne s'y attendent pas j'en suis sur :)
Alain Ketterlin
NicolasP writes:
Méta-MCI (MVP) a écrit :
Bien qu'ayant fait le ménage il y a un certain temps, il restait, dans de vieilles routines, quelques ... == None (ou ... != None). Avec Python 2.5, ça passait encore. Avec Python 2.6 (et certainement avec 3), ça accroche beaucoup plus souvent. Mais pas toujours... Pensez à bien utiliser is None @-salutations
Et ça fait quoi si on garde l'écriture == None ?
Et aussi, par curiosité, ça fait quoi si tu passes à None == ... ?
-- Alain.
NicolasP <nicolasp@aaton.com> writes:
Méta-MCI (MVP) a écrit :
Bien qu'ayant fait le ménage il y a un certain temps, il restait,
dans de vieilles routines, quelques ... == None (ou ... != None).
Avec Python 2.5, ça passait encore.
Avec Python 2.6 (et certainement avec 3), ça accroche beaucoup plus
souvent. Mais pas toujours...
Pensez à bien utiliser is None
@-salutations
Et ça fait quoi si on garde l'écriture == None ?
Et aussi, par curiosité, ça fait quoi si tu passes à None == ... ?
Bien qu'ayant fait le ménage il y a un certain temps, il restait, dans de vieilles routines, quelques ... == None (ou ... != None). Avec Python 2.5, ça passait encore. Avec Python 2.6 (et certainement avec 3), ça accroche beaucoup plus souvent. Mais pas toujours... Pensez à bien utiliser is None @-salutations
Et ça fait quoi si on garde l'écriture == None ?
Et aussi, par curiosité, ça fait quoi si tu passes à None == ... ?
-- Alain.
Michel Claveau - NoSpam SVP ; merci
Bonsoir !
Pour Nicolas et Alain.
Sous Python 2.6.1, avec x==None j'ai eu quelques cas de réponse incorrectes. J'ai eu aussi des erreurs de comparaisons de types.
Les mêmes scripts fonctionnaient sans problèmes sous Python 2.5
@-salutations -- Michel Claveau
Bonsoir !
Pour Nicolas et Alain.
Sous Python 2.6.1, avec x==None j'ai eu quelques cas de réponse
incorrectes.
J'ai eu aussi des erreurs de comparaisons de types.
Les mêmes scripts fonctionnaient sans problèmes sous Python 2.5
Sous Python 2.6.1, avec x==None j'ai eu quelques cas de réponse incorrectes. J'ai eu aussi des erreurs de comparaisons de types.
Les mêmes scripts fonctionnaient sans problèmes sous Python 2.5
@-salutations -- Michel Claveau
NicolasP
Alain Ketterlin a écrit :
NicolasP writes:
Méta-MCI (MVP) a écrit :
Bien qu'ayant fait le ménage il y a un certain temps, il restait, dans de vieilles routines, quelques ... == None (ou ... != None). Avec Python 2.5, ça passait encore. Avec Python 2.6 (et certainement avec 3), ça accroche beaucoup plus souvent. Mais pas toujours... Pensez à bien utiliser is None @-salutations
Et ça fait quoi si on garde l'écriture == None ?
Et aussi, par curiosité, ça fait quoi si tu passes à None == ... ?
Ca ne me choque pas. Où est le problème ? Quand j'écris :
toto = None ... if quelquechose() : toto = 'une chaine' ... if toto == None : fait_quelquechose()
Rien ne me parait choquant. Une "variable" est comparée à None. Et alors ? J'ai bien le droit d'écrire if toto==1 ou if toto == 'A' ou encore if toto==1.9
Maintenant, si le language interdit if toto==None, ça c'est différent.
Nicolas
Alain Ketterlin a écrit :
NicolasP <nicolasp@aaton.com> writes:
Méta-MCI (MVP) a écrit :
Bien qu'ayant fait le ménage il y a un certain temps, il restait,
dans de vieilles routines, quelques ... == None (ou ... != None).
Avec Python 2.5, ça passait encore.
Avec Python 2.6 (et certainement avec 3), ça accroche beaucoup plus
souvent. Mais pas toujours...
Pensez à bien utiliser is None
@-salutations
Et ça fait quoi si on garde l'écriture == None ?
Et aussi, par curiosité, ça fait quoi si tu passes à None == ... ?
Ca ne me choque pas. Où est le problème ?
Quand j'écris :
toto = None
...
if quelquechose() :
toto = 'une chaine'
...
if toto == None :
fait_quelquechose()
Rien ne me parait choquant.
Une "variable" est comparée à None. Et alors ?
J'ai bien le droit d'écrire if toto==1 ou if toto == 'A' ou encore if toto==1.9
Maintenant, si le language interdit if toto==None, ça c'est différent.
Bien qu'ayant fait le ménage il y a un certain temps, il restait, dans de vieilles routines, quelques ... == None (ou ... != None). Avec Python 2.5, ça passait encore. Avec Python 2.6 (et certainement avec 3), ça accroche beaucoup plus souvent. Mais pas toujours... Pensez à bien utiliser is None @-salutations
Et ça fait quoi si on garde l'écriture == None ?
Et aussi, par curiosité, ça fait quoi si tu passes à None == ... ?
Ca ne me choque pas. Où est le problème ? Quand j'écris :
toto = None ... if quelquechose() : toto = 'une chaine' ... if toto == None : fait_quelquechose()
Rien ne me parait choquant. Une "variable" est comparée à None. Et alors ? J'ai bien le droit d'écrire if toto==1 ou if toto == 'A' ou encore if toto==1.9
Maintenant, si le language interdit if toto==None, ça c'est différent.
Nicolas
Méta-MCI \(MVP\)
Salut !
Le problème vient, comme l'a indiqué Christophe, avec des objets qui ont leur propre implémentation de cmp Imagine le cas d'un objet 'portefeuille' (d'actions) héritant de list mais qui compare deux instances d'après le total (la valeur du portefeuille). Si le développeur n'a traité que le cas des portefeuilles vides, la comparaison à None fera une erreur. Comme le statut de None a évolué, on peut tomber sur des librairies qui fonctionnaient autrefois, et plantent avec les dernières implémentations de Python.
J'ai un autre cas, en multi-langages. Certains langages utilisent des notions telles que Null, Unassigned, Undefined, Blank, NaN, etc. La correspondance avec None de Python, qui est (légèrement) plus générique, peut évoluer, au fil du temps. Je me souviens d'un langage ou Blank était assimilé, autrefois à None, et maintenant à une chaîne vide (pour les strings), ou à 0 (pour les numériques).
@-salutations -- Michel Claveau
Salut !
Le problème vient, comme l'a indiqué Christophe, avec des objets qui ont
leur propre implémentation de cmp
Imagine le cas d'un objet 'portefeuille' (d'actions) héritant de list
mais qui compare deux instances d'après le total (la valeur du
portefeuille). Si le développeur n'a traité que le cas des portefeuilles
vides, la comparaison à None fera une erreur.
Comme le statut de None a évolué, on peut tomber sur des librairies qui
fonctionnaient autrefois, et plantent avec les dernières implémentations
de Python.
J'ai un autre cas, en multi-langages. Certains langages utilisent des
notions telles que Null, Unassigned, Undefined, Blank, NaN, etc. La
correspondance avec None de Python, qui est (légèrement) plus générique,
peut évoluer, au fil du temps. Je me souviens d'un langage ou Blank
était assimilé, autrefois à None, et maintenant à une chaîne vide (pour
les strings), ou à 0 (pour les numériques).
Le problème vient, comme l'a indiqué Christophe, avec des objets qui ont leur propre implémentation de cmp Imagine le cas d'un objet 'portefeuille' (d'actions) héritant de list mais qui compare deux instances d'après le total (la valeur du portefeuille). Si le développeur n'a traité que le cas des portefeuilles vides, la comparaison à None fera une erreur. Comme le statut de None a évolué, on peut tomber sur des librairies qui fonctionnaient autrefois, et plantent avec les dernières implémentations de Python.
J'ai un autre cas, en multi-langages. Certains langages utilisent des notions telles que Null, Unassigned, Undefined, Blank, NaN, etc. La correspondance avec None de Python, qui est (légèrement) plus générique, peut évoluer, au fil du temps. Je me souviens d'un langage ou Blank était assimilé, autrefois à None, et maintenant à une chaîne vide (pour les strings), ou à 0 (pour les numériques).
@-salutations -- Michel Claveau
NicolasP
Méta-MCI (MVP) a écrit :
Salut !
Le problème vient, comme l'a indiqué Christophe, avec des objets qui ont leur propre implémentation de cmp
Là, effectivement, je comprends mieux qu'il puisse y avoir un problème.
Imagine le cas d'un objet 'portefeuille' (d'actions) héritant de list mais qui compare deux instances d'après le total (la valeur du portefeuille). Si le développeur n'a traité que le cas des portefeuilles vides, la comparaison à None fera une erreur.
Tout à fait.
Comme le statut de None a évolué, on peut tomber sur des librairies qui fonctionnaient autrefois, et plantent avec les dernières implémentations de Python.
Effectivement.
Nicolas
Méta-MCI (MVP) a écrit :
Salut !
Le problème vient, comme l'a indiqué Christophe, avec des objets qui ont
leur propre implémentation de cmp
Là, effectivement, je comprends mieux qu'il puisse y avoir un problème.
Imagine le cas d'un objet 'portefeuille' (d'actions) héritant de list
mais qui compare deux instances d'après le total (la valeur du
portefeuille). Si le développeur n'a traité que le cas des portefeuilles
vides, la comparaison à None fera une erreur.
Tout à fait.
Comme le statut de None a évolué, on peut tomber sur des librairies qui
fonctionnaient autrefois, et plantent avec les dernières implémentations
de Python.
Le problème vient, comme l'a indiqué Christophe, avec des objets qui ont leur propre implémentation de cmp
Là, effectivement, je comprends mieux qu'il puisse y avoir un problème.
Imagine le cas d'un objet 'portefeuille' (d'actions) héritant de list mais qui compare deux instances d'après le total (la valeur du portefeuille). Si le développeur n'a traité que le cas des portefeuilles vides, la comparaison à None fera une erreur.
Tout à fait.
Comme le statut de None a évolué, on peut tomber sur des librairies qui fonctionnaient autrefois, et plantent avec les dernières implémentations de Python.
Effectivement.
Nicolas
Encolpe Degoute
NicolasP a écrit :
Et ça fait quoi si on garde l'écriture == None ?
C'est crade, depuis 5 ans déjà...
D'un point de vue sémantique '==' est fait pour comparer des valeurs et 'is' pour comparer des références sur les objets. 'None' n'est pas une valeur mais une absence de valeur. Utiliser '==' pour comparer deux absences de valeurs n'a pas de sens par contre vérifier qu'un objet utilise bien la référence vers l'absence de valeur est sémantiquement correct.
Mes 2 cents -- Encolpe DEGOUTE http://encolpe.degoute.free.fr/ Logiciels libres, hockey sur glace et autres activités cérébrales
NicolasP a écrit :
Et ça fait quoi si on garde l'écriture == None ?
C'est crade, depuis 5 ans déjà...
D'un point de vue sémantique '==' est fait pour comparer des valeurs et 'is' pour comparer des références sur les objets.
'None' n'est pas une valeur mais une absence de valeur.
Utiliser '==' pour comparer deux absences de valeurs n'a pas de sens par contre vérifier qu'un objet utilise bien la référence vers l'absence de
valeur est sémantiquement correct.
Mes 2 cents
--
Encolpe DEGOUTE
http://encolpe.degoute.free.fr/
Logiciels libres, hockey sur glace et autres activités cérébrales
D'un point de vue sémantique '==' est fait pour comparer des valeurs et 'is' pour comparer des références sur les objets. 'None' n'est pas une valeur mais une absence de valeur. Utiliser '==' pour comparer deux absences de valeurs n'a pas de sens par contre vérifier qu'un objet utilise bien la référence vers l'absence de valeur est sémantiquement correct.
Mes 2 cents -- Encolpe DEGOUTE http://encolpe.degoute.free.fr/ Logiciels libres, hockey sur glace et autres activités cérébrales
NicolasP
Encolpe Degoute a écrit :
NicolasP a écrit :
Et ça fait quoi si on garde l'écriture == None ?
C'est crade, depuis 5 ans déjà...
Beurk alors.
D'un point de vue sémantique '==' est fait pour comparer des valeurs et 'is' pour comparer des références sur les objets.
C'est bien de le rappeler.
'None' n'est pas une valeur mais une absence de valeur.
On peut aussi dire que None est un objet qui représente une absence de valeur. Non ?
Utiliser '==' pour comparer deux absences de valeurs n'a pas de sens par contre vérifier qu'un objet utilise bien la référence vers l'absence de valeur est sémantiquement correct.
Si mon affirmation ci-dessus est vraie, alors il n'y a pas de raison de ne pas pouvoir utiliser '=='. J'ai bien le droit de comparer un entier et un flottant, des objets qui ne sont pas du même type.
Nicolas
Encolpe Degoute a écrit :
NicolasP a écrit :
Et ça fait quoi si on garde l'écriture == None ?
C'est crade, depuis 5 ans déjà...
Beurk alors.
D'un point de vue sémantique '==' est fait pour comparer des valeurs et 'is' pour comparer des références sur les objets.
C'est bien de le rappeler.
'None' n'est pas une valeur mais une absence de valeur.
On peut aussi dire que None est un objet qui représente une absence de valeur. Non ?
Utiliser '==' pour comparer deux absences de valeurs n'a pas de sens par contre vérifier qu'un objet utilise bien la référence vers l'absence de
valeur est sémantiquement correct.
Si mon affirmation ci-dessus est vraie, alors il n'y a pas de raison de ne pas pouvoir utiliser '=='.
J'ai bien le droit de comparer un entier et un flottant, des objets qui ne sont pas du même type.
D'un point de vue sémantique '==' est fait pour comparer des valeurs et 'is' pour comparer des références sur les objets.
C'est bien de le rappeler.
'None' n'est pas une valeur mais une absence de valeur.
On peut aussi dire que None est un objet qui représente une absence de valeur. Non ?
Utiliser '==' pour comparer deux absences de valeurs n'a pas de sens par contre vérifier qu'un objet utilise bien la référence vers l'absence de valeur est sémantiquement correct.
Si mon affirmation ci-dessus est vraie, alors il n'y a pas de raison de ne pas pouvoir utiliser '=='. J'ai bien le droit de comparer un entier et un flottant, des objets qui ne sont pas du même type.
Nicolas
Daireaux Jean-Baptiste
NicolasP a écrit :
Encolpe Degoute a écrit :
NicolasP a écrit :
[[CUT]]
J'ai bien le droit de comparer un entier et un flottant, des objets qui ne sont pas du même type.
Nicolas
Non tu n'a pas le droit de comparer un entier et un flottant, t'a toujours un trans-typage de caché dans l'opération (en l'occurrence transformation de l'entier en flottant) avant la comparaison.
J.B.D.
NicolasP a écrit :
Encolpe Degoute a écrit :
NicolasP a écrit :
[[CUT]]
J'ai bien le droit de comparer un entier et un flottant, des objets qui
ne sont pas du même type.
Nicolas
Non tu n'a pas le droit de comparer un entier et un flottant, t'a
toujours un trans-typage de caché dans l'opération (en l'occurrence
transformation de l'entier en flottant) avant la comparaison.
J'ai bien le droit de comparer un entier et un flottant, des objets qui ne sont pas du même type.
Nicolas
Non tu n'a pas le droit de comparer un entier et un flottant, t'a toujours un trans-typage de caché dans l'opération (en l'occurrence transformation de l'entier en flottant) avant la comparaison.
