Syntax and types: Python through a JS/TS lens

Blocks are whitespace; variables are just names

Python has no braces and no semicolons. A block is a run of lines at the same indentation under a header line ending in :. The indentation is the syntax — mixing tabs and spaces, or being off by one space, is a IndentationError, not a style nit. The community standard (PEP 8) is four spaces.

def classify(n: int) -> str:
    if n < 0:
        return "negative"
    elif n == 0:
        return "zero"
    return "positive"          # same level as the if → still in classify

Variables need no keyword. There is no let, const, or var: assignment both declares and binds. And a name is a reference to an object, exactly like a JS object reference — b = a does not copy a list, it makes b point at the same list, so mutating through one is visible through the other. Python has no built-in const; immutability is a property of the value (tuples, strings, frozensets are immutable), not of the binding.

a = [1, 2, 3]
b = a            # b references the SAME list, no copy
b.append(4)
print(a)         # [1, 2, 3, 4] — mutated through b

The numeric tower: int, float, and two division operators

JavaScript has one number type — an IEEE-754 double — so 9999999999999999 silently loses precision. Python’s int is arbitrary-precision: it grows to whatever size the value needs, no overflow, no silent rounding. float is the IEEE-754 double you know. The trap for JS developers is division: / always produces a float, even on two ints, and // is floor division (rounds toward negative infinity).

type(2 ** 100)        # <class 'int'> — 1267650600228229401496703205376, exact
7 / 2                 # 3.5    (float, always)
7 // 2                # 3      (floor division, int)
-7 // 2               # -4     (floors toward -infinity, not toward zero)
7 % 3                 # 1      (modulo)

Strings are immutable sequences. Interpolation is the f-string — Python’s template literal — using {} instead of ${}, and it can hold any expression: f"{name} has {len(items)} items". There is no implicit number-to-string coercion: "x" + 1 is a TypeError, not "x1".

Truthiness, None, and the == vs is gotcha

Like JS, Python has truthiness, but the falsy set differs: False, None, 0, 0.0, "", and every empty collection ([], {}, (), set()) are falsy; everything else is truthy. So if items: is the idiomatic “is this list non-empty?” check — there is no separate length > 0 ceremony.

None is Python’s single nullish value — it replaces both JS null and undefined. There is no undefined; a missing attribute raises, a missing dict key raises, and an absent argument defaults to whatever you declared (commonly None). The idiomatic test is if x is None:, not == None, because None is a singleton and identity is exact and fast.

That brings the real gotcha. == compares value; is compares identity (whether two names point at the literally same object in memory). JS has nothing exactly like is — === is still a value comparison for primitives. Confusing them is the classic bug, and it’s made sneaky by small-int caching: CPython pre-allocates the integers from −5 to 256, so is accidentally returns True for small ints and False for large ones.

a = 256;  b = 256
a is b          # True  — both are the SAME cached object

x = 257;  y = 257
x is y          # False — two distinct objects (value-equal, not identity-equal)
x == y          # True  — value comparison, the one you actually wanted

[] == []        # True  — equal value
[] is []        # False — two separate list objects

Rule of thumb: use is only for None, True, False, and sentinel singletons; use == for everything else. Booleans are themselves a subclass of int — True == 1 and False == 0 are True — another sharp edge when you compare loosely.

Type hints describe; they do not enforce

If you’re coming from TypeScript with the expectation that annotating a parameter as int actually stops a str from getting through at runtime — this section is the one that will save you a production incident.

This is the deepest break from TypeScript. Python’s type hints (PEP 484) look like TS annotations — def f(x: int) -> str:, count: int = 0, items: list[str] — but the interpreter ignores them at runtime. Passing a str where an int is hinted runs fine until something actually breaks on the value. Hints are checked statically by a separate tool — mypy or pyright — that you run in CI; they are essentially advisory metadata stored in __annotations__.

def repeat(s: str, n: int) -> str:
    return s * n

repeat("ab", 3)       # 'ababab' — correct
repeat(3, "x")        # hints say (str, int) but Python never checks:
                      # 3 * "x" runs and returns 'xxx' — wrong types, no error, a silent bug
repeat("ab", "3")     # "ab" * "3" — TypeError at runtime, since str * str is invalid

The TS contrast is subtle. TS types are also erased at compile time — they don’t exist at runtime either. The difference is ecosystem and enforcement: in TS, code that fails the type-checker normally doesn’t ship (the build fails); in Python, the program runs regardless of whether you ever ran mypy. Treat hints as documentation that a checker can verify, not as a runtime guard. If you need runtime validation, that’s a library (Pydantic, dataclasses with checks), not the type system.