Encapsulation is one of the most misunderstood concepts in Python, especially by developers coming from Java, C++, or C#.

Python does not implement encapsulation through access modifiers. And that’s not a weakness, it’s a design choice.

This article explains encapsulation in Python the way senior engineers actually reason about it:
through state ownership, mutation control, and reference safety.

Why Python Doesn’t Have Private Members (And Why That’s Good)

Python does NOT have:

• private, protected, public
• compiler-enforced access control
• true private fields

Python does have:

• name binding
• attribute lookup rules
• conventions (PEP 8)
• descriptors and properties
• composition over restriction

Encapsulation in Python is social, not technical.

This philosophy is intentional. Python assumes developers are responsible adults, not adversaries.

How Instance State Actually Works in Python

Consider this simple class:

class User:
    def __init__(self, name):
        self.name = name

u = User("Rahul")
print(u.__dict__)

• Instance attributes live in obj.__dict__
• There is no protective barrier
• Any code can mutate them

u.__dict__["name"] = "Hello"
assert u.name == "Hello"

The language does not enforce encapsulation.

The Convention: _single_underscore vs __double_underscore

_single_underscore (PEP 8 Convention)

class A:
    def __init__(self):
        self._x = 100

• Means: internal use
• Defined by PEP 8
• Zero enforcement

This is documentation for humans, not protection from code.

__double_underscore (Name Mangling)

class A:
    def __init__(self):
        self.__x = 10

internally becomes

• A_x

class A:
    def __init__(self):
        self.__x = 10
a = A()
print(a._A__x == getattr(a, f"_{a.__class__.__name__}__x"))
print(a.__x)

True
Traceback (most recent call last):
  File "/dev/shm/7b53ddd9-8a73-43bb-b844-7eb8ad350351/main.py", line 6, in <module>
    print(a.__x)
          ^^^^^
AttributeError: 'A' object has no attribute '__x'

Why Name Mangling Exists

• Prevents accidental overrides in subclasses
• Helps with MRO safety
• NOT about privacy or security

If you know the class name, you can always access the attribute.

The Real Encapsulation Problem: Shared Mutable References

Encapsulation in Python does NOT break because attributes are public. It breaks when mutable state escapes.

The “Reference Leak” Trap (Critical Concept)

class Bag:
    def __init__(self):
        self.items = []

b = Bag()
x = b.items
x.append(1)

print(b.items)
# [1]

What Went Wrong?

• b.items and x reference the same list
• The mutation happened outside the object
• No method was called
• No validation occurred

Encapsulation breaks when an object loses exclusive control over its mutable state.

Defensive Copy: Restoring Encapsulation

from copy import deepcopy

class Bag:
    def __init__(self, items):
        self.__items = deepcopy(items)

    def get_items(self):
      # we will update it when using properties
      return self.__items

bag = [1, 2, 3]
b = Bag(items=bag)
bag.append(100)
assert bag != b.get_items()

• Ownership is explicit
• External mutation does not leak
• Object controls its state again

@property: Controlled Access (True Encapsulation)

class User:
    def __init__(self, age):
        self._age = age

    @property
    def age(self):
        return self._age

u = User(10)
print(u.age)

Looks like attribute access. Behaves like a method.

This is actually a descriptor magic which we are going to talk about in next article.

Adding Validation with a Setter

class User:
    def __init__(self, age):
        self.age = age

    @property
    def age(self):
        return self._age

    @age.setter
    def age(self, value):
        if value < 0:
            raise ValueError("Age cannot be negative")
        self._age = value

u = User(10)
try:
  u.age = -19
except ValueError as e:
  print(e)

try:
  u2 = User(-10)
except ValueError as e:
  print(e)

print(u.age)

Age cannot be negative
Age cannot be negative
10

This is real encapsulation in Python.

Encapsulation with @dataclass(frozen=True)

Python encourages immutability.

from dataclasses import dataclass

@dataclass(frozen=True)
class Config:
    host: str
    port: int

config = Config('localhost', '80')
print(config)
config.host = '127.0.0.1'

Config(host='localhost', port='80')
Traceback (most recent call last):
  File "/dev/shm/bae3641b-e0a1-403d-8565-19b31fd1d9da/main.py", line 10, in <module>
    config.host = '127.0.0.1'
    ^^^^^^^^^^^
  File "<string>", line 16, in __setattr__
dataclasses.FrozenInstanceError: cannot assign to field 'host'

But it doesn’t use deepcopy, so for reading, it is thread-safe until you want to break your own design, as i did in this example.

from dataclasses import dataclass

@dataclass(frozen=True)
class Config:
    host: str
    port: int
    di: dict

di = {'a': 'b'}
config = Config('localhost', '80', di=di)
print(config)
di.update({"b": "c"})
print(config)

# Config(host='localhost', port='80', di={'a': 'b'})
# Config(host='localhost', port='80', di={'a': 'b', 'b': 'c'})

Feeling bored while reading this article? I would suggest to visit source at

Why Your Python Encapsulation is Broken (And How Seniors Fix It)

and experiment with the code in the code editor side by side.

Class vs Instance Attributes (Encapsulation Trap)

class A:
    x = []

a1 = A()
a2 = A()

a1.x.append(1)
assert a2.x == A.x == a1.x == [1]

Why This Happens

• x is a class attribute
• Shared across all instances

Correct Pattern

class A:
    def __init__(self):
        self.x = []

__slots__: Advanced Encapsulation & Memory Control

Normally, Python objects use a dictionary (__dict__) to store attributes. Dictionaries are flexible but "fat"—they consume a lot of RAM because they use a hash table to allow you to add new attributes at runtime.

By defining __slots__, You tell Python: "Don't create a dictionary. Only reserve space for these specific attributes."

class User:
    __slots__ = ("name", "age")

    def __init__(self, name, age):
        self.name = name
        self.age = age

u = User(name="A", age=50)
print(u.name, u.age)
assert hasattr(u, '__dict__') is False

try:
  u.new_attr = 100
except Exception as e:
  print(e)

A 50
'User' object has no attribute 'new_attr' and no __dict__ for setting new attributes

A Few “Authority” Gotchas to Remember

1. Inheritance Breakage (The “Hidden Dict” Trap)

If a parent class is a “standard” Python class, it creates a __dict__. Even if the child uses __slots__, it inherits that dictionary from the parent, defeating the memory-saving purpose.

class Parent:
    def __init__(self):
        self.a = 1  # This goes into a __dict__

class Child(Parent):
    __slots__ = ("b",)
    def __init__(self):
        super().__init__()
        self.b = 2

obj = Child()
print(hasattr(obj, "__dict__"))
obj.random_attr = "I shouldn't be here!" # Works! (Slots failed to restrict)
print(obj.__dict__)
print(obj.__slots__)

True
{'a': 1, 'random_attr': "I shouldn't be here!"}
('b',)

2. No Weak References

A “Weak Reference” allows the garbage collector to reclaim an object even if a weakref exists. Standard objects support this by default. Slotted objects do not.

import weakref

class SlottedUser:
    __slots__ = ("name",)

u = SlottedUser()
try:
    r = weakref.ref(u)
except TypeError as e:
    print(f"Error: {e}")


class NormalUser:
   pass

u = NormalUser()
try:
    r = weakref.ref(u)
    print("worked")
except TypeError as e:
    print(f"Error: {e}")

Error: cannot create weak reference to 'SlottedUser' object
worked

The Fix: You must explicitly reserve space for the weak reference machinery.

import weakref

class SlottedUser:
    __slots__ = ("name", "__weakref__")

u = SlottedUser()
try:
    r = weakref.ref(u)
    print("worked")
except TypeError as e:
    print(f"Error: {e}")

We are going to cover WeakRef and why they are useful in our upcoming articles. It is one of the concepts that is related to Python's garbage collector, so I will highly recommand to read this article this article.

Python's Memory DNA: A Senior Guide to Identity, Interning, and GC

Encapsulation Is About Ownership

Ask these questions:

• Who owns this state?
• Who is allowed to mutate it?
• Can a mutation happen without the object knowing?
• Is immutability possible?

If mutation leaks -> encapsulation is broken.

If you’re looking to level up your architecture, I’d highly recommend checking out the SOLID principles. They’re basically the gold standard for writing clean, maintainable code. This series is a great place to start.

SOLID Principles Series - All Articles

Final Takeaways

• Python does not enforce encapsulation via access modifiers
• _ and __ are conventions and collision-avoidance tools
• Mutable reference leaks are the real enemy
• @property, immutability, and defensive copying are core tools
• dataclass(frozen=True) and __slots__ signal senior-level design
• Encapsulation is about control, not visibility

References

• Python Language Reference — Data Model
• Python Documentation — property()
• PEP 8 — Style Guide for Python Code
• PEP 557 — Data Classes
• Python Documentation slots

Hello everyone — it’s been a while since I last wrote on Medium.

I’ve been heads-down building TakoVibe, a modern writing platform for developers, and that journey has taught me far more than I expected. From experimenting with new frontend frameworks to designing the UI, handling deployments, setting up automation, and making real infrastructure decisions — it’s been a hands-on learning experience in every sense.

While building TakoVibe, one decision kept coming back to bite me: choosing the right VPS.

Like many developers, I assumed bigger specs meant better performance. More cores, more RAM, a seemingly great deal — what could go wrong? As it turns out, quite a lot.

In this post, I want to share the lessons I learned the hard way — especially around CPU cores, latency, oversubscription, and why “bigger” VPS plans often feel slower in real life. If you’re hosting a blog, a platform, or any developer-facing product, this might save you both money and frustration.

Choosing A VPS

When choosing a VPS, most developers fall into a simple mental model:

More cores + more RAM = better performance

On paper, it makes sense. In reality, it’s often wrong.

I recently moved from a “bigger” VPS (8 Core, 24 GB RAM, France) to a smaller one (6 Cores, 12 GB RAM, Mumbai).

Same Workload but lower cost, and yet — everything felt faster.

The illusion of “more cores.”

A VPS does not give you physical CPU cores. It gives you vCPUs, which are slices of shared hardware.

Providers routinely oversubscribe CPUs:

Oversubscription = virtual CPUs sold / physical CPU cores

Typical ratios:

• Cheap VPS: 8:1–16:1
• Mid-tier VPS: 4:1–8:1
• High-quality VPS: 2:1–4:1
• Dedicated servers: 1:1

So that “12-core VPS” may actually be competing with dozens of other tenants on the same host.

That’s why providers love selling big-RAM plans on weak CPUs.

CPU generation matters more than core count

Here’s the uncomfortable truth:

Six modern cores can outperform ten old ones.

Older VPS plans often run on CPUs like:

• Intel Haswell (2013-era, Mine one)
• Early Xeons with heavy security mitigations

Modern VPS plans run on:

• AMD EPYC Milan (Mine one)/ Genoa (Zen 3 / Zen 4)
• Intel Ice Lake / Sapphire Rapids

What changed?

• Much higher IPC (instructions per cycle)
• Better branch prediction
• Better memory subsystems
• Fewer performance-killing security penalties

In real workloads (Node, Python, databases, builds), single-core speed dominates.

Why I Chose a Bigger VPS — and Why I Left It

When I first chose my VPS, I went for the bigger one.

It was my first time seeing a machine with 12 cores and 24 GB RAM for around $18, and it felt like a steal. I also liked the idea that it was a full-fledged Linux server — something I could use not just for hosting my blog, but also for development and even learning a bit of machine learning.

On paper, it looked perfect. But very quickly, the cracks started to show.

The first issue was latency. I was using VS Code Server on the VPS, and every interaction had a noticeable delay. It wasn’t unusable, but it constantly reminded me that I wasn’t working locally — and that discomfort adds up fast when you code every day.

The second realization was more subtle. Even though I knew it before buying, I was never going to use the full specs. I tried hosting multiple services on the VPS, including a VPN, but none of that justified the hardware. The machine was powerful, yet my experience felt slower.

Latency turned out to be the real deal breaker.

That’s when I decided to switch to a smaller VPS — $9, located in Mumbai (India).

This time, I optimized for two things: region and CPU architecture.

The difference was immediate. Latency dropped drastically. My hosted VS Code Server started feeling almost like it was running locally. That alone made the switch worth it.

I also noticed that my frontend builds felt slightly faster. I can’t prove it with benchmarks, but given the newer CPU architecture, it wouldn’t be surprising.

Ironically, the “smaller” server felt more capable — because it was better aligned with how I actually work.

Why the “bigger” VPS still exists

So if smaller modern CPUs are better, why do providers still sell huge plans on old hardware?

Because:

• Hardware is already paid for: Old servers are cheap to operate and highly profitable.
• Most buyers compare numbers, not generations: “24 GB RAM” sounds safer than “12 GB RAM”.
• Many workloads need memory, not speed: JVMs, caches, batch jobs, legacy systems.

Those plans aren’t scams — they’re just optimized for a different audience.

Oversubscription + throttling = inconsistent performance

Two more concepts complete the picture:

• Oversubscription: too many vCPUs share the same physical core pool
• Throttling: the provider intentionally limits sustained usage

Symptoms you’ve probably seen:

• Builds start fast, then slow down
• CPU usage never reaches 100%
• Random latency spikes

Latency beats raw specs

Region choice often matters more than hardware.

For my Indian users:

• Europe → ~120–180 ms RTT
• Mumbai → ~15–30 ms RTT

If the platform continues to grow, I plan to expand by adding servers in other regions to better serve users globally.

That difference is immediately noticeable in:

• TTFB (Time to First Byte, a core web performance metric)
• API calls
• SSR pages
• Database round-trip

You can’t fix latency with more RAM.

The rule that actually works

After going through this firsthand, here’s the rule I now follow:

Fewer modern cores > many old cores

Closer region > bigger machine

CPU quality > CPU quantity

For most web workloads:

• Blogs
• APIs
• Dashboards
• CI/CD
• Small–medium SaaS

When “more cores” really does make sense

To be fair, bigger VPS plans are still the right choice for:

• In-memory databases ( Like Redis)
• Heavy background workers
• Batch processing
• Data pipelines

But if your workload is request-driven and latency-sensitive, raw core count is the wrong metric.

Myth: “More CPU Cores Means I Can Run an LLM for Free”

A common misconception is that having more CPU cores means you can host an LLM for free and serve responses to users without the need for GPUs.

On paper, it sounds reasonable. In practice, it quickly falls apart.

Why this idea breaks down

When an LLM runs inference on a CPU, it does not use one or two cores politely. Token generation is compute-heavy and typically fans out across all available cores to reduce latency.

The result?

• Your entire CPU gets saturated
• Other workloads (SSR, APIs, background jobs) get stalled
• Your server becomes effectively single-purpose

At that point, your “multi-core” server behaves like a single-request machine.

Concurrency becomes a nightmare

With CPU-based LLM inference:

• One request can easily consume 100% of the available CPU
• Multiple concurrent requests do not scale linearly
• Requests start queueing instead of running in parallel

Now imagine:

• 50–100 users hit “Generate” at the same time
• Your server tries to satisfy all of them
• Latency explodes, or the process gets OOM (Out of Memory) killed

That’s not a scaling problem — that’s a catastrophe waiting to happen.

When CPU inference does make sense

To be fair, CPU inference is reasonable for:

• Local experimentation
• Offline batch processing
• Low-QPS internal tools
• Very small models (≤3B parameters)

Final takeaway

The VPS market sells comfort, not performance.

Big numbers feel safe.Modern CPUs feel fast.

Thank you for reading till the end. Don’t forget to follow Rahul Beniwal for more real experiences.

More CPU Cores, Worse Performance: The VPS Buying Mistake Most Developers Make was originally published in Level Up Coding on Medium, where people are continuing the conversation by highlighting and responding to this story.