2015-06-11 11 views
8

Mi chiedevo il motivo di avere un operatore non uguale in python.Perché c'è un operatore non uguale in python

i seguenti snipped:

class Foo: 
    def __eq__(self, other): 
     print('Equal called') 
     return True 

    def __ne__(self, other): 
     print('Not equal called') 
     return True 

if __name__ == '__main__': 
    a = Foo() 

    print(a == 1) 
    print(a != 1) 
    print(not a == 1) 

uscite:

Equal called 
True 
Not equal called 
True 
Equal called 
False 

non fa questo in realtà invitare un sacco di problemi da potenzialmente dicendo:

A == B and A != B 

possono essere corrette al contemporaneamente. Inoltre questo introduce un potenziale trabocchetto quando si dimentica di implementare __ne__.

+0

Ottimizzazione? E questo è contro i contratti. –

+8

* "Non ci sono relazioni implicite tra gli operatori di confronto.La verità di' x == y' non implica che 'x! = Y' sia falso.Pertanto, quando si definisce' __eq __() ', si dovrebbe anche definire' __ne __() 'in modo che gli operatori si comportino come previsto." * – CoryKramer

+0

@CoryKramer Da dove viene? – vmonteco

risposta

-1

Sembra che stai restituendo True invece di fare il confronto.

+1

In realtà non ha problemi con il suo frammento di codice. Sta chiedendo perché il linguaggio è stato progettato così com'è. – Kevin

+0

Lo hanno fatto deliberatamente per dimostrare un punto.Python ti permette di commettere delle contraddizioni logiche – CoryKramer

+0

Penso che sia intenzionale. – vmonteco

7

A seconda delle esigenze, ci sono casi in cui uguali e non uguali non sono opposti; tuttavia, la maggior parte dei casi sono opposti, quindi in Python 3 se non si specifica un metodo __ne__, Python invertirà il metodo __eq__ per l'utente.

Se si sta scrivendo il codice per eseguire su Python 2 e Python 3, è necessario definire entrambi.

+0

Anche NaN è stato il mio primo pensiero, ma l'ho appena testato e non riesco a trovare una situazione in cui i due confronti non restituiscano risultati opposti. –

+0

Hm, non sono d'accordo. Dovrebbe essere definito dalla libreria se NaN è uguale a qualsiasi numero di no. Sono d'accordo con il secondo punto, tranne quando la sottoclasse è ancora una potenziale trappola. –

+0

@MarkRansom: Ah, giusto, grazie. Risolto quel punto. –

1

Per la data model documentation, che copre le "metodi magici" è possibile implementare sulle classi (sottolineatura mia):

ci sono relazioni implicite tra gli operatori di confronto. La verità di x==y non implica che x!=y sia false. Di conseguenza, quando definisce __eq__(), è necessario definire anche __ne__() in modo che gli operatori si comportino come previsto.

+0

Mi piacerebbe vedere un esempio pratico in cui è utile avere '__eq__' e' __ne__' comportarsi in modo incoerente. –

+1

@MarkRansom che ne dite di 'numpy', dove' == 'e'! = 'Sugli array creano matrici di confronto booleano elemento-saggio? 'x! = y' dà una matrice,' not x == y' dà un 'ValueError'! – jonrsharpe

Problemi correlati