Python OOP — Private Methods & Private Variables

The Story That Explains Private Members

The Problem — Python Makes Everything Public by Default

When you write self.balance = 1000 in __init__, any caller can reach into that object and change account.balance = -1_000_000. Nothing stops them. That's fine for a script, but for a real class it's a disaster.

class BankAccount:
    def __init__(self, holder, balance):
        self.holder  = holder
        self.balance = balance         # public — anyone can touch it

acc = BankAccount("Alice", 1000)

# Nothing stops this — the whole class contract is gone
acc.balance = -99999999
print(acc.balance)   # -99999999   ← no validation, no history, no protection

Single Underscore _protected — "Please Knock"

A name that starts with one underscore (self._log, self._retries) is a hint to every reader: "this is internal to the class. Don't touch it from outside unless you know what you're doing." Python itself does nothing special — no mangling, no access errors. It's a pure convention, universally respected in the community.

class BankAccount:
    def __init__(self, holder, balance):
        self.holder   = holder         # public — okay to read/write
        self._log     = []             # protected — internal use, but subclasses can extend
        self._version = 1              # protected — for internal bookkeeping

acc = BankAccount("Alice", 1000)

# You CAN still touch _log from outside — Python doesn't stop you...
print(acc._log)          # []   (works — but you shouldn't)

# ...but every Python developer reads "_log" as "don't touch, this is internal."

Double Underscore __private — Name Mangling Locks the Safe

A name that starts with two underscores (and doesn't end in two) triggers Python's name mangling. Python quietly renames self.__balance behind the scenes to self._ClassName__balance. Anyone who tries the obvious account.__balance from outside gets an AttributeError.

class BankAccount:
    def __init__(self, holder, balance):
        self.holder    = holder
        self.__balance = balance       # private — will be renamed by Python
        self.__pin     = None          # private — you REALLY can't leak this

    def show(self):
        # Inside the class, __balance works as expected
        print(f"{self.holder}: ${self.__balance}")

acc = BankAccount("Alice", 1000)
acc.show()                       # Alice: $1000

# ── The obvious access from outside FAILS ──
try:
    print(acc.__balance)
except AttributeError as e:
    print("Blocked:", e)         # 'BankAccount' object has no attribute '__balance'

# ── What Python actually did: it renamed the attribute ──
print(acc.__dict__)              # {'holder': 'Alice', '_BankAccount__balance': 1000, '_BankAccount__pin': None}

# ── You COULD still reach it via the mangled name, but everyone knows you're cheating ──
print(acc._BankAccount__balance) # 1000 — works, but any reviewer will reject this

Animated Diagram — Public vs Protected vs Private Access

Three attributes on one BankAccount. Watch what happens when outside code tries to reach each of them. Public wins instantly, protected works but with a "you shouldn't" warning, private crashes with an AttributeError.

Animated Diagram — How Name Mangling Works

When Python compiles the class body, any name starting with __ (and not ending in __) is silently rewritten. The rule is simple: prepend _ClassName. Inside the class, self.__balance and the mangled name behave identically. From outside, only the mangled name works.

Private Methods — Helpers That Should Never Be Called From Outside

Everything you learned about private variables applies to private methods identically. A method whose name starts with __ gets name-mangled just like an attribute. Use this to hide implementation details — validation, formatting, internal setup — that callers should never care about.

class User:
    def __init__(self, username, password):
        self.username = username
        self.__password_hash = self.__hash(password)   # uses private method

    # ── Public API ─────────────────────────────────────
    def check_password(self, guess):
        return self.__password_hash == self.__hash(guess)

    # ── Private helper — never called from outside ─────
    def __hash(self, s):
        # In real code: hashlib.sha256(...). Toy here.
        return hex(hash(s))

alice = User("alice", "secret")
print(alice.check_password("secret"))    # True   (public method works)
print(alice.check_password("guess"))     # False

# Calling the private helper from outside → AttributeError
try:
    alice.__hash("anything")
except AttributeError as e:
    print("Blocked:", e)

Animated Diagram — Public API Calls Private Helpers

Outside code only ever calls the public method withdraw(500, pin). Behind that door, the method invokes several private helpers — __verify(), __log_txn() — that the caller never sees or knows about. That's encapsulation.

Practical Example — BankAccount With Private Balance and PIN

A realistic small class that uses all three access levels together: a public API, protected logging that subclasses may extend, and truly private state (balance, PIN) that only the class itself touches through private helper methods.

class BankAccount:
    def __init__(self, holder, opening_balance, pin):
        if not BankAccount.__is_valid_pin(pin):
            raise ValueError("PIN must be 4 digits")
        self.holder    = holder            # public — the customer's name
        self._log      = []                # protected — subclasses may extend
        self.__balance = opening_balance   # private — the whole point of a bank
        self.__pin     = pin               # private — should NEVER leak

    # ══ PUBLIC API — the only entry points ═══════════════════
    def deposit(self, amount, pin):
        self.__verify(pin)
        if amount <= 0:
            raise ValueError("Amount must be positive")
        self.__balance += amount
        self.__log_txn("deposit", amount)

    def withdraw(self, amount, pin):
        self.__verify(pin)
        if amount > self.__balance:
            raise ValueError("Insufficient funds")
        self.__balance -= amount
        self.__log_txn("withdraw", amount)

    def get_balance(self, pin):
        # Even reading the balance requires the PIN
        self.__verify(pin)
        return self.__balance

    # ══ PRIVATE HELPERS — hidden implementation details ══════
    def __verify(self, pin):
        if pin != self.__pin:
            raise PermissionError("Wrong PIN")

    def __log_txn(self, action, amount):
        self._log.append((action, amount))

    @staticmethod
    def __is_valid_pin(pin):
        return isinstance(pin, str) and len(pin) == 4 and pin.isdigit()


# ── Normal use — everything works through the public API ───
acc = BankAccount("Alice", opening_balance=1000, pin="1234")
acc.deposit(500, pin="1234")
acc.withdraw(200, pin="1234")
print("Balance:", acc.get_balance(pin="1234"))     # Balance: 1300
print("Log:    ", acc._log)                    # protected — visible but internal

# ── Attempts to bypass the API ─────────────────────────────
try: acc.withdraw(100, pin="9999")
except PermissionError as e: print("Blocked:", e)   # wrong PIN

try: print(acc.__balance)
except AttributeError as e: print("Blocked:", e)    # direct read fails

try: acc.__verify("9999")
except AttributeError as e: print("Blocked:", e)    # private helper is not callable

Public API vs Private Implementation — The Contract

Common Mistakes (and Fixes)

Quick Reference

Golden Rules