4 ms·
The confusion there is caused by english not disambiguating between equality and being-the-exact-same-thing-ness. I'll grant that "is" is a bit of a footgun for
by Doxin 6y ago
The confusion there is caused by english not disambiguating between equality and being-the-exact-same-thing-ness. I'll grant that "is" is a bit of a footgun for new users, but it's not a WTF in the sense that the language is doing something weird.
Rule of thumb is use == for everything except True/False/None. Once you get going with python you'll learn the meaning of is eventually, and you'll still barely ever need to use it.
- GoblinSlayer 6y agoWhy that exception?
- maweki 6y agoNone, True, False are singletons and are never constructed again after initilization of the interpreter (and have been keywords in python2). That's why "is" is always safe. Small integers, as they are kept around, probably are as well (5 is (2+3) works). I think what gets dropped during the conversation is, that we've been living with Java doing it this way (is being == and == being .equals) for decades and nobody really complains.
- deleted 6y ago[deleted]
- GoblinSlayer 6y agoI mean why not use == for everything?
- Vaphell 6y ago1. it's a slower check, just like equals() intended for value equality is slower than reference equality == in java. 2. 1 == True and 0 == False, as booleans subclass the int type. On the other hand is distingushes between 1 and True, and 0 and False respectively.
- EForEndeavour 6y agoNoob question: instead of using == except for True/False/None, what about just using == for all comparisons?