Should I ever use is on strings?

Only after sys.intern, and only in performance-critical code where you control every string involved.

Why the SyntaxWarning?

Because x is "text" is almost always a bug, and the interpreter can tell.

Is x is None faster than x == None?

Yes, and use it because it is correct: == can be redefined by a class, identity cannot.

Do other implementations intern the same strings?

No. PyPy and Jython differ, which is another reason not to depend on it.

How do I compare identity in a set?

Store id(obj) — and keep a reference to the object, since ids are reused after garbage collection.

The negation, and x is not None is the idiomatic form. Not to be confused with not x is None, which parses the same but reads worse.

Why does `is` sometimes work on strings?

Q: Why does is sometimes work on strings?

Interning makes identical literals share one object. It is an optimisation, not a guarantee.

Interview QuestionsBy Ashish JangraUpdated 30 August 2026

CPython interns short string literals that look like identifiers, so two of them share one object and is happens to be True. Build the same text at runtime and it is False. It is an optimisation, not a guarantee — compare strings with ==, and keep is for None.

Overview

The two operators

== compares values. is compares identity — whether two names refer to the same object in memory.

1Python

a = "hello"
b = "hello"
print(a == b)          # True  -- same characters
print(a is b)          # True  -- and, here, the same object

x = "hello world!"
y = "hello world!"
print(x == y)          # True
print(x is y)          # True or False, depending on how they were created

Output

That last pair is the whole problem: is on strings gives answers that depend on interpreter internals, so code relying on it works in testing and fails somewhere else.

The rule is short: use == for values, and is only for None, True, False, and genuine identity checks.

StringsConceptualMedium

Step through it

What to watch

Both rows hold the same text; only how it was built differs.
== is True in every frame. is is not.
Behaviour differs between the REPL and a script — which is the point.

Say this out loud

"That's interning - CPython reuses one object for short literals. It's an implementation detail, so I compare with == and only use `is` for None."

# Interning: why `is` sometimes agrees with `==`, and why you cannot trust it. import sys a = "hello" b = "hello" # identical literal - interned c = "hel" + "lo" # folded at compile time - usually interned too parts = ["hel", "lo"] d = "".join(parts) # built at RUNTIME - not interned for name, value in [("b", b), ("c", c), ("d", d)]: print(f"a is {name}: {str(a is value):>5} a == {name}: {a == value} " f"id: {hex(id(value))}") print() # Spaces stop a literal looking like an identifier. e = "hello world" f = "hello world" g = "hello" + " world" print("e is f (two literals) :", e is f) print("e is g (built by +) :", e is g) print("e == g :", e == g, "<- the only one that matters") # Opting in deliberately is a different thing entirely. print() d2 = sys.intern(d) print("after sys.intern(d), a is d2:", a is d2) # Small integers have the same story, and the same trap. print() x, y = 256, 256 p, q = 257, 257 print("256 is 256:", x is y, " 257 is 257:", p is q) print("CPython caches -5..256. Nothing in the language promises that.")

String	Interned?
String literals in source code	Usually
Identifier-like text (`"abc"`, `"x_1"`)	Usually
Containing spaces or punctuation	Often not
Built at runtime by concatenation	No
Read from a file or network	No
Short: `""`, single characters	Yes

String

Interned?

String literals in source code

Usually

Identifier-like text ("abc", "x_1")

Usually

Containing spaces or punctuation

Often not

Built at runtime by concatenation

Read from a file or network

Short: "", single characters

Yes

import sys x = None old_list = [1, 2, 3] new_list = old_list a = "hello" b = "hello" print(a is b) # True -- literal, identifier-like c = "".join(["hel", "lo"]) print(a is c) # False -- built at runtime print(a == c) # True -- and equal, which is what matters print(sys.intern(c) is a) # True -- forced into the table

x, flag = None, True if x is None: print("x is None :", x is None) if flag is True: # when you mean the object, not truthiness print("flag is True :", flag is True) print("1 == True :", 1 == True, "but 1 is True ->", 1 is True)

_MISSING = object() def get(key, default=_MISSING): store = {"a": 1} if key in store: return store[key] if default is _MISSING: # only identity can test this raise KeyError(key) return default print("present :", get("a")) print("default :", get("zzz", "fallback")) try: get("zzz") except KeyError as e: print("no default:", type(e).__name__ + ":", e)

Comparison	Result	Why
`1 == 1.0`	True	Numeric types compare across types
`1 == True`	True	`bool` subclasses `int`
`float("nan") == float("nan")`	False	IEEE 754 requires it
`[] == ()`	False	Different types, no cross-comparison
`"café" == "café"`	False	Different Unicode normalisation
`Decimal("0.1") == 0.1`	False	Binary float is not exactly 0.1

Comparison

Result

Why

1 == 1.0

True

Numeric types compare across types

1 == True

True

bool subclasses int

float("nan") == float("nan")

False

IEEE 754 requires it

[] == ()

False

Different types, no cross-comparison

"café" == "café"

False