0

Just when I though I knew enough about python operators!

Can someone explain why e is f false?

a = 'Goodbye'
b = 'Goodbye'
c = 'Good_Bye'
d = 'Good_Bye'
e = 'Good-Bye'
f = 'Good-Bye'
a is b
Out[9]: True
c is d
Out[10]: True
e is f
Out[11]: False
Pankaj Singh
  • 526
  • 7
  • 21
  • 1
    It is implementation-dependent whether any two identical string literals produce references to a single shared object or two distinct objects. – chepner Sep 25 '20 at 14:55
  • 2
    Does this answer your question? [Why does comparing strings using either '==' or 'is' sometimes produce a different result?](https://stackoverflow.com/questions/1504717/why-does-comparing-strings-using-either-or-is-sometimes-produce-a-differe) – ggorlen Sep 25 '20 at 14:56
  • @ggorlen - No, it doesnt actually... My question is very specific about value 'Good-Bye'. Something about the '-' in that string that is causing the id to be different. – Pankaj Singh Sep 25 '20 at 18:42
  • 1
    I think you're missing the point of the dupe. When and how CPython creates and stores strings is an implementation detail that has nothing to do with the `"-"` specifically, and if it does, it's totally an internal detail you've stumbled on that is basically meaningless to reason about as a user of the CPython interpreter and may well change in future (or past) versions. Please read the entire dupe chain thoroughly--doing `string is some_other_string` is fundamentally incorrect and unpredictable. – ggorlen Sep 25 '20 at 18:42
  • @ggorlen - Yeah, I think I a missing something here... I do see your point. Just that why is the behavior consistent, it is meant to be inconsistent. Let me do the reading you mentioned – Pankaj Singh Sep 25 '20 at 19:56

1 Answers1

1

is checks for identity of two objects.

The ‘is’ operator compares the identity of two objects; the id() function returns an integer representing its identity.

For immutable (e.g. str) literals, equal values can (incidentally) actual rely on the same object underpinning them, but that is not guaranteed or intentional -> you should not rely on that (emphasis added):

Types affect almost all aspects of object behavior. Even the importance of object identity is affected in some sense: for immutable types, operations that compute new values may actually return a reference to any existing object with the same type and value, while for mutable objects this is not allowed. E.g., after a = 1; b = 1, a and b may or may not refer to the same object with the value one, depending on the implementation.

Ondrej K.
  • 8,841
  • 11
  • 24
  • 39
  • So, that part I understand... What is it about the value 'Good-Bye' though. Something about the '-' in that string that is causing the id to be different. – Pankaj Singh Sep 25 '20 at 18:43
  • 1
    I see. Well that is not a question about how `is` operator, but about objects of specific `str` literals. And for that as doc says, they "may or may not" be identical for the equal value thereof. It's for the interpret to decide, but the most important part is, it is a **behavior you must not rely on**, because while it may work one way in a specific interpreter of a specific version on your machine, it may not work the same way anywhere and everywhere else. – Ondrej K. Sep 25 '20 at 20:01
  • 1
    Btw. the behavior of your specific example with my interpreter seems to also depend whether it runs interactively (or from a file / or piped in). – Ondrej K. Sep 25 '20 at 20:20