Hacker News Reader

Comment by serial_dev | Hacker News Reader

I agree with most of your points, because in most cases, people try something very weird, and they are surprised that the result is something even weirder (or they just didn't think through the example logically).

Except the string comparison with "is". It's confusing, because there are no errors, and when I try them in the Python REPL, it "works". The code is logical, I tested the example and it works...

...except when it doesn't, but if I'm just a naive beginner, I'll need to learn the hard way that it doesn't always work

For this reason, I'd be okay with saying that "it" for strings is a WTF of the language.

View on HN

In python, strings are mostly unique, meaning that a string can be bound on many variables, and all the variables point to the same string. This is where the 'is' operator comes in, 'is' checks for reference equality, that is, the object that is bound onto the two variables is the same. If they are not the same, 'is' fails.

In other words:

    x = "foo"
    y = "foo"
    x == y and x is y

Both strings point to the same exact memory. Hence, 'is' works. But it isn't always true:

    x = "foo"
    y = f"{x} "[:-1] # get everything but the space
    x == y # True
    y is x # False

Checking for reference equality (comparing pointers) is such a niche requirement it should be hidden behind stronger syntactic vinegar. The greatest mistake Java made maybe is having == for testing pointers, and .equals() function for actually comparing.

Every JVM language that came after Java reverses this. Here, "is" simply is too nice. Should've named it something nobody will accidentally use.

> Checking for reference equality (comparing pointers) is such a niche requirement it should be hidden behind stronger syntactic vinegar.

In python it’s common due to `None`, which you really want to check by identity. Other placeholders as well. This is such a major use case that in 3.9 `is` was moved out of the generic `compare_op` instruction and into its own.

And because __eq__ can be overridden, aside from being noticeably slower `x == None` is not truly reliable.

It’s not even that. CPython happens to sue memory address as ID, but the language doesn’t require that. You could easily use something else for the object ID and get completely different behavior.

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.

Noob question: instead of using == except for True/False/None, what about just using == for all comparisons?

Why that exception?

None, 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.

I mean why not use == for everything?

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

Reply on news.ycombinator.com