2

Why does this code print "not equals" instead of throwing a TypeError?

int_num = 1
str_num = "2"

if str_num == int_num:
    print("equal")
else:
    print("not equal")
martineau
  • 119,623
  • 25
  • 170
  • 301
ajster
  • 55
  • 5
  • 4
    Why would you expect it to throw a TypeError? – Wondercricket Jan 26 '22 at 17:35
  • 1
    You can compare ints with strings they just don't compare equally. – It_is_Chris Jan 26 '22 at 17:35
  • 6
    Because it's not a type error to compare objects of two different types for equality. (You will get a TypeError if you do an inequality comparison, like `int_num < str_num`, because there isn't any defined behavior for deciding whether a string is greater or lesser than a number.) – Samwise Jan 26 '22 at 17:35
  • Please provide a reference to docs that made you believe that `TypeEroor` was to be triggered. – PM 77-1 Jan 26 '22 at 17:36
  • 1
    @Wondercricket Because it’s a very controversial, and arguably incorrect, API design. There are reasons why Python does it like this but it’s far from the only conceivable implementation, and it’s almost certainly not the best. – Konrad Rudolph Jan 26 '22 at 17:37
  • 1
    It's pretty unambiguous that `1` is not the same as `"2"`, so returning `False` seems unambiguously correct to me... – Samwise Jan 26 '22 at 17:38
  • 7
    Because Guido, and the rest of the Python crowd, decided many years ago that comparing objects of different types should not be an error. This may or may not have been wise, but that's the way it is. (Now do JavaScript.) – molbdnilo Jan 26 '22 at 17:38
  • 2
    @Wondercricket It's a reasonable expectation. Plenty of languages will throw type errors either at compile-time or run-time. It just so happens Python isn't one of them. I mean the language does has a `TypeError` exception which indicates it does do type checks in some capacity. I'm not surprised the OP is surprised. – John Kugelman Jan 26 '22 at 17:38
  • 2
    Regardless of whether it's the better or worse choice, this feels like a "why was this language design choice made" question which are typically discouraged due to their subjective nature. – Axe319 Jan 26 '22 at 17:45
  • 2
    Apart from being opinion based and not a very useful question (the obvious answer is *this is how the language was designed*), this is just a duplicate... Does this answer your question? [Python: Why does equality comparing an int with a string not throw an error?](https://stackoverflow.com/q/10617737/6045800) – Tomerikoo Jan 26 '22 at 17:47
  • @Tomerikoo Duplicate, for sure. “Not very useful”, I find debatable: it’s a surprising behaviour to some, and it trips plenty of people up, despite being documented as such. – Konrad Rudolph Jan 26 '22 at 18:01
  • Did not expected the question to be controversial. Coming from a Java background it was surprising and odd but 'it is what it is'. Next time I'll know to check before scratching my head for hours :) – ajster Jan 27 '22 at 19:27

2 Answers2

4

From the current Python documentation for Comparisons:

Objects of different types, except different numeric types, never compare equal. The == operator is always defined...

(Emphasis mine.)

martineau
  • 119,623
  • 25
  • 170
  • 301
Random Davis
  • 6,662
  • 4
  • 14
  • 24
3

How comparisons are defined for standard types:

Objects of different types, except different numeric types, never compare equal. The == operator is always defined but for some object types (for example, class objects) is equivalent to is. The <, <=, > and >= operators are only defined where they make sense; for example, they raise a TypeError exception when one of the arguments is a complex number.

Non-identical instances of a class normally compare as non-equal unless the class defines the __eq__() method.

Equality would work on any objects though:

By default, object implements __eq__() by using is, returning NotImplemented in the case of a false comparison: True if x is y else NotImplemented.

martineau
  • 119,623
  • 25
  • 170
  • 301
Roman Pavelka
  • 3,736
  • 2
  • 11
  • 28
  • 2
    this has nothing to do with the question. It's comparing an `int` and a `str` and asking why there is no type error – Green Cloak Guy Jan 26 '22 at 17:41
  • It is the only possible objective answer besides digging threads from 20 years ago regarding Python's design. – amiasato Jan 26 '22 at 17:43
  • @GreenCloakGuy You are right, added a part on standard types and kept the part on general objects... Will improve it more. – Roman Pavelka Jan 26 '22 at 17:51