I still remember the first time I saw a Python class method with self and wondered why it felt so verbose. Coming from languages that quietly pass the instance behind the scenes, I expected Python to do the same. Instead, Python chooses to make the instance visible in every method signature, and that one design decision shapes how you read, debug, and extend object-oriented code. If you’ve ever felt that self is redundant, you’re not alone—but once you see why it exists, it starts to feel like a power tool rather than a requirement.

In this post I’ll walk through why Python uses self as the default instance argument, how method binding actually works, and what practical benefits this design gives you in real projects. I’ll also cover common mistakes, when to bend the convention, and how self influences testing, inheritance, and even performance. If you write Python for web backends, data pipelines, ML tooling, or automation scripts, this topic touches your code daily, so it’s worth understanding deeply.

The explicit instance argument is the point

Python’s object model is built on a simple idea: methods are functions that receive an object as their first parameter. That object is the instance you’re operating on. Python doesn’t try to hide that; it puts it directly in the method signature so you see, at call time, exactly what data is being acted on.

That’s why Python uses self as the default name for that first parameter. It’s not a keyword, it’s not magic, and you can name it anything. But the convention is so strong that breaking it usually harms readability more than it helps.

Here’s the essential pattern:

class Car:
def init(self, brand, model):
self.brand = brand  # Set instance attribute
self.model = model  # Set instance attribute
def display(self):
return self.brand, self.model
Create an instance of Car
car1 = Car("Toyota", "Corolla")
Call the display method
print(car1.display())

Output:

(‘Toyota‘, ‘Corolla‘)

When you call car1.display(), Python really executes Car.display(car1). The instance is explicit, and that helps you reason about how attributes are read and written. I’ve seen teams catch subtle bugs simply because this model makes data flow obvious.

What “default argument” actually means here

People often say “self is a default argument” but that’s not quite correct in the same way as default parameter values like def f(x=3). self is the conventional name for the first parameter in instance methods, and Python automatically supplies that argument during method calls. It’s “default” in the social sense: everyone writes it that way, and the runtime expects the first parameter to represent the instance.

So when you write:

class Logger:
def log(self, message):
print(message)
logger = Logger()
logger.log("ready")

the function stored on the class is actually a plain function object. When accessed through an instance, Python binds that function to the instance and creates a bound method, implicitly providing self as the first argument.

If you access the function directly from the class instead of an instance, you have to pass the instance yourself:

Logger.log(logger, "ready")

That’s not an error or a hack; it’s the real mechanism. Knowing this makes debugging and metaprogramming far easier in my experience.

Why Python refuses to make it implicit

Languages like Java, C#, and JavaScript hide the instance reference (or use a special keyword like this) so that you don’t see the object in the method signature. Python goes the other way for a few reasons:

1) Explicit is better than implicit. This is a core Python principle. When you open a class and see def save(self, path):, you know instantly that save operates on instance state. You don’t have to guess which variables are global, which are class-level, and which belong to the object.

2) Uniformity across functions. In Python, a method is still just a function. That means you can pass it around, wrap it, decorate it, or replace it at runtime. The explicit self keeps the function signature consistent with Python’s general function model.

3) Clarity in inheritance. When methods are overridden, the explicit instance argument removes ambiguity about which object’s state is being accessed. You can inspect a signature and know how arguments flow, even in multiple inheritance scenarios.

I’ve found that this explicitness reduces the number of “magic” assumptions developers make. It encourages a style where object state is visible and deliberate.

How method binding really works

Python’s method binding is often described as “automatic,” but it’s worth seeing the mechanics. When you access a function on a class, you get the raw function object. When you access it on an instance, Python uses the descriptor protocol to create a bound method.

Let’s look at an example that shows the difference:

class Device:
def status(self):
return f"Device id={id(self)}"
sensor = Device()
Access via instance: bound method
bound = sensor.status
Access via class: function
unbound = Device.status
print(bound())              # works
print(unbound(sensor))      # works

This is why the first parameter exists at all. The binding process injects the instance as the first argument. Without it, Python would need a separate function type just for methods, which would complicate the object model and reduce the flexibility that makes Python expressive.

When I build metaprogramming tools or instrumentation (for example, tracing method calls), this model lets me treat methods and functions uniformly. That consistency matters in large systems.

Self and object initialization in practice

self matters most during initialization, where you decide which attributes belong to the instance. The key idea is that every instance has its own namespace (a dict or slots), and self is how you access it.

class Course:
def init(self, topic):
self._topic = topic  # Store parameter value in instance variable
def show_topic(self):
print("Topic:", self._topic)
Creating an instance of Course
course = Course("Python")
Calling the method
course.show_topic()

Output:

Topic: Python

If you remove self and write topic = topic, you’re only modifying a local variable, not the instance. That’s a very common early mistake, and it’s precisely why Python keeps the instance argument visible in method signatures. When you see self._topic, you know it’s stored on the object.

The self name is a convention, and that’s a strength

Because self isn’t reserved, you can rename it. You’ll sometimes see cls for class methods or this in code written by developers coming from other languages. But I don’t recommend renaming self in ordinary code. In teams, conventions are your shared language.

I’ve reviewed projects where someone used this in Python class methods. The code executed fine, but it slowed down everyone else’s reading. In fast-moving codebases, readability is part of performance. Use self unless you have a very strong reason not to.

The same principle applies to cls in class methods. It’s not a keyword either, but consistent naming makes patterns instantly recognizable:

class Registry:
_items = []
@classmethod
def add(cls, item):
cls._items.append(item)

I treat these conventions as “soft rules” that keep Python code simple and predictable.

A simple analogy that actually helps

When I explain self to newer engineers, I use a mailroom analogy. Think of a method as a letter instructing a mailroom to do something. The mailroom needs an address, otherwise the instruction is meaningless. self is that address. Without it, “place the package on the shelf” doesn’t tell you which shelf in which building.

This analogy is not perfect, but it captures the key idea: the method doesn’t float in the void; it acts on a specific instance. Python makes that association explicit so that you can see the address in every method signature.

Why this matters in real systems

In production code, self is more than a naming convention. It shapes architecture, testing strategies, and debugging workflows.

• When diagnosing state bugs, self helps you see exactly which object is holding the value.
• When designing APIs, it encourages you to keep state local to instances rather than hidden in globals.
• When patching methods for tests, explicit self keeps mocks predictable.

I’ve worked on services where a subtle bug came from accidentally using a class attribute instead of an instance attribute. Because methods explicitly use self, that mistake stood out quickly during review. If the instance reference were implicit, the difference would have been easier to miss.

Common mistakes with self (and how I fix them)

Here are the mistakes I see most often, along with the fixes I recommend:

1) Forgetting self in method definitions

class Account:
def deposit(amount):  # incorrect
self.balance += amount

This breaks because Python still tries to pass the instance, and your method signature can’t accept it.

Fix:

class Account:
def deposit(self, amount):
self.balance += amount

2) Shadowing self accidentally

class Sensor:
def update(self, self_value):
self = self_value  # incorrect

You’re just reassigning the local name self. It doesn’t change the instance.

Fix: use a different parameter name, and store on self:

class Sensor:
def update(self, value):
self.value = value

3) Mixing class attributes and instance attributes

class Counter:
count = 0
def increment(self):
self.count += 1

This creates an instance attribute shadowing the class attribute. Sometimes that’s intended, but often it’s not. If you want a global count across instances, use Counter.count += 1. If you want per-instance state, initialize in init.

I often add a short test case to check that multiple instances don’t interfere with one another. That keeps these bugs out of production.

When to use self, and when not to

You should use self for instance methods—methods that need access to instance state. You should avoid it in two other types of methods:

• Static methods: Use when the function does not depend on the instance or the class. It’s just a utility function that happens to live in the class namespace.

class Math:
@staticmethod
def clamp(value, low, high):
return max(low, min(value, high))

• Class methods: Use when the method operates on the class itself, not a specific instance.

class Config:
_cache = {}
@classmethod
def from_env(cls, name, default=None):
return cls._cache.get(name, default)

I recommend a clear rule: if the method needs instance data, use self. If it only needs class data, use cls. If it needs neither, use @staticmethod and make that explicit.

Performance considerations: what actually matters

Passing self has a negligible cost. The overhead of method calls in Python is already small compared to I/O, network calls, or heavy computation. In my benchmarks, the difference between a bound method call and a standalone function call is usually in the low microseconds range on modern hardware, and it rarely matters unless you’re in a tight loop doing millions of operations per second.

If you are in that rare performance-critical path, the big wins usually come from algorithm choice, data layout, or using native extensions—not from removing self. If you need speed, I’d first consider:

• Using built-in types and methods rather than Python loops
• Vectorizing work with NumPy or Polars
• Offloading inner loops to Cython, Rust, or a JIT like PyPy

In other words, treat self as a clarity feature, not a performance concern.

Self and inheritance: clarity across layers

Inheritance is one of the places where the explicit instance argument shines. When I see def save(self): in a subclass, I know that method will receive the same instance type as the subclass, not the base class. That matters when the subclass adds new state.

class BaseModel:
def save(self):
print("Saving", self.class.name)
class User(BaseModel):
def init(self, email):
self.email = email
def save(self):
super().save()
print("Email:", self.email)

Because self is explicit, you can easily trace which object is being saved and which attributes are available. This clarity becomes critical in multiple inheritance, where method resolution order (MRO) can be tricky.

When I debug MRO problems, I often inspect method signatures and follow self through each call chain. The explicit instance reference makes that possible without guesswork.

Binding behavior and descriptors: the advanced view

If you work with metaclasses, decorators, or descriptors, you’ll eventually run into the get protocol, which is how Python binds methods. Understanding this is optional for everyday coding, but it’s the reason self exists at all.

A function on a class is a descriptor. When you access it through an instance, function.get(instance, owner) returns a bound method that carries the instance along. That’s why self is injected.

Why do I care about this? Because it lets you build powerful tools:

• Method wrappers that enforce permissions or tracing
• Lazy-loading attribute access
• Runtime patching for tests or hotfixes

When you design such tools, the explicit first argument allows you to intercept or modify calls in a predictable way. Python doesn’t have a separate “method type” beyond this descriptor mechanism, and self is the bridge.

The “self is optional” myth and why it hurts teams

You will occasionally see code that avoids self by using free functions or static methods for everything. While that can be acceptable in purely functional styles, it often leads to an architecture where state is stored in global variables or passed around as loose dictionaries. This can work for scripts, but I don’t recommend it for long-lived services.

In large systems, the presence of self in method signatures becomes a powerful signal: “this code depends on instance state.” Removing that signal makes code harder to reason about. My rule: if there’s state, bind it to an object and make that explicit with self.

Table: explicit instance vs implicit instance

Here’s a simplified comparison that I use in code reviews. It’s not about right vs wrong; it’s about clarity vs convenience.

Aspect

Explicit instance (self)

Implicit instance (hidden reference) —

—

— Readability

High, signature shows instance use

Medium, must infer from body Debugging

Easier to trace data flow

More guesswork Metaprogramming

Natural, uniform with functions

Requires special rules Consistency

Uniform across functions/methods

Separate “method” concept Learning curve

Slightly steeper at first

Slightly easier at first

I’d rather pay the small learning cost upfront to gain long-term clarity and tooling benefits.

Real-world scenario: multiple instances, separate state

The following example shows why self matters when you have many objects of the same class.

class Circle:
def init(self, r):
self.r = r
def area(self):
a = 3.14  self.r * 2
return a
Creating instances
small = Circle(3)
big = Circle(10)
print("Small:", small.area())
print("Big:", big.area())

Output:

Small: 28.26
Big: 314.0

Because self.r is bound to each instance, each object calculates area using its own radius. If you used a class attribute instead, both instances would collide. The explicit self ensures that attributes are always instance-specific unless you explicitly choose otherwise.

Self, mutability, and safe design

self also reminds you that methods can mutate object state. That’s not always desirable. In modern Python, I often use immutable patterns where methods return new instances instead of changing the current one. But when you do mutate, self makes that mutation explicit.

For example, a configuration object could be written in a mutable style:

class Settings:
def init(self):
self.flags = {}
def enable(self, name):
self.flags[name] = True

Or in a more immutable style:

class Settings:
def init(self, flags=None):
self.flags = dict(flags or {})
def enable(self, name):
# Return a new Settings instance instead of mutating
new_flags = dict(self.flags)
new_flags[name] = True
return Settings(new_flags)

In both cases, self makes the design intent visible. I’ve found that this clarity reduces unintended side effects, especially in concurrent or async systems.

How self interacts with modern Python tooling

In 2026, Python development is heavily assisted by static analyzers, type checkers, and AI tools. self plays a central role in making those tools effective:

• Type checkers use self to infer instance attributes, especially with self.attribute = value patterns.
• Language servers use self to provide autocomplete for instance methods and fields.
• AI-assisted code generation uses the self pattern to infer class layout and propose correct method bodies.

If you obscure or rename self, you make those tools less reliable. I’ve seen teams lose valuable editor hints because of inconsistent naming. Keeping self consistent helps your tools help you.

Self and testing: writing more precise unit tests

In test suites, explicit instance passing can be a feature. Sometimes I call methods directly on classes with a constructed instance to test a method in isolation, or to bypass side effects from the normal instantiation flow.

Example: a class that loads data in init but has a pure formatting method you want to test:

class Report:
def init(self, data):
self.data = data
def format_title(self):
return f"Report: {self.data[‘title‘]}"
Test with a lightweight instance
r = Report({"title": "Sales"})
assert Report.format_title(r) == "Report: Sales"

This is not a common pattern, but it’s possible because methods are just functions with an explicit instance argument. The model stays simple even in tests.

Edge cases that can surprise you

Even experienced developers get tripped up by a few self-related edge cases:

1) Assigning attributes dynamically

class User:
def init(self, email):
self.email = email
u = User("[email protected]")
setattr(u, "role", "admin")

Now u.role exists. This is legal because instance namespaces are dynamic. The explicit self makes it obvious that attributes are instance-specific, not fixed. But it can also create silent bugs if you mistype a name. I often use slots in performance-critical or safety-critical classes to prevent this.

2) Overriding methods with different signatures

If a subclass changes the signature and forgets self, it breaks polymorphism. Keep the first parameter consistent across overrides.

3) Binding methods as callbacks

When passing self.method to a callback, it’s already bound. You don’t need to pass self again. I’ve seen this mistake in async frameworks:

# Incorrect
loop.callsoon(self.handleevent, self)
Correct
loop.callsoon(self.handleevent)

Understanding binding saves you from double-argument errors.

When I recommend bending the convention

There are rare cases where I intentionally break the self naming convention:

• Domain-specific languages or internal frameworks where a different name improves clarity. For example, in a GUI toolkit, using widget instead of self might make callback signatures clearer. I still do this sparingly and only in tightly scoped code.
• Auto-generated code where the generator uses a different name consistently across the codebase. In that case, consistency within the generated output matters more than the global convention.

Even then, I document the rationale clearly. When in doubt, I stick with self.

Why not make self a keyword?

This question comes up a lot. If self were a keyword, Python could enforce the convention and prevent mistakes like def save(slef, path):. But it would also make Python less flexible. You’d be unable to use self as a normal variable name, and it would break backward compatibility with existing code that uses other names for the instance parameter.

Python favors conventions over strict enforcement. That choice keeps the language simple and adaptable. It also encourages developers to take responsibility for readability rather than relying on syntax rules to enforce it.

What about dataclasses and attrs?

Dataclasses and libraries like attrs do a lot of work for you, but they still rely on self inside methods. You can auto-generate init, repr, and comparisons, but when you add behavior, self remains the explicit instance reference.

This pattern stays true even as Python evolves. The more automation you add, the more valuable a clear, stable convention becomes. In my experience, self is part of the “mental API” of Python. It doesn’t change, and that stability is a feature.

Self and documentation: a subtle advantage

Docstring tools, autodoc, and documentation generators often inspect signatures. Because self is explicit, tooling can distinguish between instance methods and static or class methods. That improves doc quality and avoids ambiguity.

When I build developer portals or SDK docs, this is a small but real advantage: the documentation reflects the class design accurately without guessing which methods are tied to instance state.

Practical guidance you can apply today

If you take one thing away, let it be this: self isn’t a quirky Python habit—it’s the core of Python’s object model. It tells you, the reader, which object the method operates on, and it keeps functions and methods consistent. Here are the practices I recommend in everyday code:

• Always use self for instance methods and cls for class methods.
• Initialize instance attributes in init to avoid accidental class attributes.
• Use explicit method binding patterns when debugging or testing.
• Avoid renaming self unless you have a narrow, clear reason.
• Prefer clarity over cleverness; explicit instance passing makes code easier to maintain.

These habits have saved me and my teams hours of debugging and review time over the years.

Key takeaways and what to do next

self exists because Python treats methods as functions and chooses clarity over hidden behavior. Once you understand method binding, it stops feeling like ceremony and starts feeling like a reliable tool. You get better readability, more predictable inheritance, and more powerful tooling. Most importantly, you get code that explains itself when you return to it months later—or when a teammate reads it for the first time.

If you’re teaching Python, I recommend introducing self early and showing how method calls are just function calls with an instance argument. If you’re building a library or API, keep your self usage consistent so your users can follow your intent. And if you’re debugging a strange class behavior, check where self points and which attributes are being attached to it.

As a next step, I’d suggest reviewing a few classes in your own codebase and asking: “Is the instance state clear from the method signatures and attribute assignments?” If not, refactor toward more explicit self usage. You’ll end up with code that’s easier to reason about and easier to extend—which is exactly what Python’s design is trying to encourage.