Python Encapsulation: Public, Protected, and Private

Key Insights

Python uses naming conventions rather than enforced access modifiers—single underscore for protected, double underscore for name-mangled private, and no prefix for public.
Name mangling with double underscores provides obfuscation, not true privacy, and should be used sparingly to prevent genuine naming conflicts in subclasses.
Property decorators offer the best of both worlds: simple attribute-like access externally while maintaining control through getters and setters internally.

Introduction to Encapsulation in Python

Encapsulation is one of the fundamental principles of object-oriented programming, allowing you to bundle data and methods while controlling access to that data. Unlike Java or C++ where access modifiers like private and protected are enforced by the compiler, Python takes a radically different approach: it relies on conventions and trusts developers to respect boundaries.

This philosophy stems from Python’s core principle: “We’re all consenting adults here.” The language assumes developers are responsible enough not to mess with internals they shouldn’t touch. While this might seem loose compared to stricter languages, it offers flexibility and reduces boilerplate while still providing mechanisms to signal intent.

Let’s see all three access levels in action:

class Employee:
    def __init__(self, name, salary):
        self.name = name              # Public
        self._department = "Engineering"  # Protected
        self.__salary = salary        # Private
    
    def get_details(self):            # Public method
        return f"{self.name} - {self._department}"
    
    def _calculate_bonus(self):       # Protected method
        return self.__salary * 0.1
    
    def __encrypt_ssn(self):          # Private method
        return "***-**-****"

Public Attributes and Methods

Everything in Python is public by default. If you don’t prefix an attribute or method with an underscore, it’s meant to be accessed from anywhere—inside the class, from subclasses, or from external code.

Public members form your class’s API—the interface that other parts of your application interact with. Use public access for anything that’s part of the intended functionality:

class ShoppingCart:
    def __init__(self):
        self.items = []  # Public attribute
        self.total = 0.0
    
    def add_item(self, item, price):
        """Public method - part of the cart's interface"""
        self.items.append(item)
        self.total += price
    
    def get_item_count(self):
        """Public method - safe to call from anywhere"""
        return len(self.items)

# Direct access is expected and encouraged
cart = ShoppingCart()
cart.add_item("Laptop", 999.99)
print(cart.total)  # 999.99
print(cart.items)  # ['Laptop']

The key is intention: if you want others to use it, make it public. Don’t prefix it with underscores just because you think it looks more “professional” or “secure.”

Protected Members (Single Underscore Convention)

The single underscore prefix (_name) signals that an attribute or method is intended for internal use within the class and its subclasses. It’s a convention that says, “You can access this, but you probably shouldn’t unless you know what you’re doing.”

Importantly, Python doesn’t enforce this protection—it’s purely a signal to other developers:

class Database:
    def __init__(self, connection_string):
        self._connection = None  # Protected attribute
        self._connect(connection_string)
    
    def _connect(self, connection_string):
        """Protected method - internal implementation detail"""
        self._connection = f"Connected to {connection_string}"
        print(self._connection)
    
    def query(self, sql):
        """Public method - uses protected members internally"""
        if self._connection:
            return f"Executing: {sql}"
        return "Not connected"

class OptimizedDatabase(Database):
    def _connect(self, connection_string):
        """Subclass can override protected methods"""
        self._connection = f"Optimized connection to {connection_string}"
        print(self._connection)

# You CAN access protected members, but the underscore warns you
db = Database("localhost:5432")
print(db._connection)  # Works, but you're ignoring the convention

# Protected members are accessible in subclasses (expected use)
opt_db = OptimizedDatabase("localhost:5432")

Use protected members for implementation details that subclasses might need to access or override, but that aren’t part of the public API. This includes helper methods, internal state, and extension points for inheritance.

Private Members (Name Mangling)

Double underscore prefixes (__name) trigger Python’s name mangling mechanism. When you use __attribute, Python internally renames it to _ClassName__attribute. This makes it harder (but not impossible) to access from outside the class:

class SecureVault:
    def __init__(self, secret):
        self.__secret = secret  # Private attribute
    
    def __encrypt(self, data):  # Private method
        return f"encrypted_{data}"
    
    def reveal(self):
        """Public method can access private members"""
        return self.__encrypt(self.__secret)

vault = SecureVault("password123")

# Direct access fails
try:
    print(vault.__secret)
except AttributeError as e:
    print(f"Error: {e}")  # 'SecureVault' object has no attribute '__secret'

# But you can still access via the mangled name if you really want to
print(vault._SecureVault__secret)  # password123

# Private methods are also mangled
print(vault._SecureVault__encrypt("data"))  # encrypted_data

Name mangling isn’t about security—it’s about preventing accidental name collisions in inheritance hierarchies. Use it when you have attributes that absolutely should not be overridden by subclasses:

class Counter:
    def __init__(self):
        self.__count = 0  # Won't collide with subclass attributes
    
    def increment(self):
        self.__count += 1
        return self.__count

class ExtendedCounter(Counter):
    def __init__(self):
        super().__init__()
        self.__count = 100  # Different from parent's __count
    
    def get_extended_count(self):
        return self.__count

counter = ExtendedCounter()
counter.increment()
print(counter.get_extended_count())  # 100 (not affected by parent)

Property Decorators and Getters/Setters

Properties provide the most Pythonic way to control attribute access. They let you use simple attribute syntax while maintaining control through getter and setter methods:

class Temperature:
    def __init__(self, celsius):
        self.__celsius = None  # Private storage
        self.celsius = celsius  # Uses setter for validation
    
    @property
    def celsius(self):
        """Getter - called when accessing temp.celsius"""
        return self.__celsius
    
    @celsius.setter
    def celsius(self, value):
        """Setter - called when assigning to temp.celsius"""
        if value < -273.15:
            raise ValueError("Temperature below absolute zero!")
        self.__celsius = value
    
    @property
    def fahrenheit(self):
        """Computed property - no setter needed"""
        return self.__celsius * 9/5 + 32
    
    @fahrenheit.setter
    def fahrenheit(self, value):
        self.celsius = (value - 32) * 5/9  # Convert and use celsius setter

# Clean interface that looks like direct attribute access
temp = Temperature(25)
print(temp.celsius)      # 25
print(temp.fahrenheit)   # 77.0

temp.celsius = 30        # Validation happens automatically
temp.fahrenheit = 32     # Sets celsius to 0

try:
    temp.celsius = -300  # Raises ValueError
except ValueError as e:
    print(f"Invalid: {e}")

Properties are ideal when you need validation, computed values, or want to refactor direct attribute access into controlled access without breaking existing code.

Real-World Use Case

Here’s a practical example combining all access levels appropriately:

class BankAccount:
    def __init__(self, account_number, initial_balance=0):
        self.account_number = account_number  # Public - part of identity
        self.__balance = initial_balance      # Private - sensitive data
        self._transaction_history = []        # Protected - for subclasses
    
    @property
    def balance(self):
        """Read-only access to balance"""
        return self.__balance
    
    def deposit(self, amount):
        """Public interface for deposits"""
        if amount <= 0:
            raise ValueError("Deposit amount must be positive")
        self.__update_balance(amount)
        self._record_transaction("deposit", amount)
    
    def withdraw(self, amount):
        """Public interface for withdrawals"""
        if amount <= 0:
            raise ValueError("Withdrawal amount must be positive")
        if amount > self.__balance:
            raise ValueError("Insufficient funds")
        self.__update_balance(-amount)
        self._record_transaction("withdrawal", amount)
    
    def __update_balance(self, amount):
        """Private - core balance logic shouldn't be overridden"""
        self.__balance += amount
    
    def _record_transaction(self, transaction_type, amount):
        """Protected - subclasses might want to extend this"""
        self._transaction_history.append({
            'type': transaction_type,
            'amount': amount
        })

class SavingsAccount(BankAccount):
    def _record_transaction(self, transaction_type, amount):
        """Override to add interest tracking"""
        super()._record_transaction(transaction_type, amount)
        if transaction_type == "deposit":
            self._calculate_interest()
    
    def _calculate_interest(self):
        """Protected helper for subclass-specific logic"""
        interest = self.balance * 0.01
        print(f"Interest calculated: ${interest:.2f}")

# Usage
account = SavingsAccount("ACC123", 1000)
account.deposit(500)
print(account.balance)  # 1500 - read-only property

# Can't directly modify balance
try:
    account.balance = 5000
except AttributeError:
    print("Can't set balance directly")

# Private method is name-mangled
# account.__update_balance(100)  # AttributeError

Best Practices and Common Pitfalls

Choose public by default. Don’t add underscores prematurely. If something is meant to be used, make it public. Over-encapsulation creates unnecessary barriers and makes code harder to test and debug.

Use single underscore for internal implementation. Mark methods and attributes with _ when they’re implementation details that might change, but that aren’t part of the public contract.

Reserve double underscore for name collision prevention. Don’t use __private just to feel secure. Use it only when you genuinely need to prevent subclass attribute collisions.

Prefer properties over getters/setters. Python isn’t Java. Don’t write get_name() and set_name(). Use properties to maintain clean attribute-style access while adding validation when needed.

Here’s what to avoid:

# Over-engineered - unnecessary encapsulation
class BadExample:
    def __init__(self, name):
        self.__name = name
    
    def get_name(self):
        return self.__name
    
    def set_name(self, name):
        self.__name = name

# Better - appropriate encapsulation
class GoodExample:
    def __init__(self, name):
        self._name = name  # Protected if validation might be added later
    
    @property
    def name(self):
        return self._name
    
    @name.setter
    def name(self, value):
        if not value:
            raise ValueError("Name cannot be empty")
        self._name = value

# Best - simple when no validation needed
class BestExample:
    def __init__(self, name):
        self.name = name  # Just public

Remember that Python’s approach to encapsulation is about communication, not enforcement. Use these conventions to signal your intent to other developers, but don’t fight the language trying to create Java-style strict privacy. Embrace the flexibility while maintaining clear boundaries through naming conventions and properties.