Fundamentals 8 min read

Why Explicit self Must Remain in Python

Bruce Eckel suggested removing the explicit 'self' parameter from Python class methods, but this article explains why keeping 'self' is essential for clear instance referencing, error messages, method types, decorators, and language compatibility, arguing that the proposal would introduce ambiguity and break existing conventions.

Python Programming Learning Circle
Python Programming Learning Circle
Python Programming Learning Circle
Why Explicit self Must Remain in Python

Bruce Eckel posted a blog proposing the removal of the explicit self parameter from Python class method signatures. The author of this article argues that the proposal cannot be accepted.

Python uses self to distinguish instance variable references from other variables, and the author notes that the suggestion stems from a desire to reduce typing and avoid occasional forgetfulness of the self argument, which can lead to confusing error messages.

Example of a typical class with self :

class C: def meth(self, arg): self.val = arg return self.val

After applying Bruce's proposal, the method would look like:

class C: def meth(arg): # Look ma, no self! self.val = arg return self.val

The author points out that while this saves a few characters, the real issue is the loss of clarity and the introduction of ambiguous error messages, such as:

Traceback (most recent call last): File "classes.py", line 9, in <module> obj.m2(1) TypeError: m2() takes exactly 3 arguments (2 given)

Keeping self preserves the theoretical equivalence of calls like foo.meth(arg) == C.meth(foo, arg) , which relies on the first parameter being the instance.

Explicit self also enables dynamic insertion of functions into classes, creating class methods without ambiguity. For example:

# Define an empty class: class C: pass # Define a global function: def meth(myself, arg): myself.val = arg return myself.val # Attach the function as a method: C.meth = meth

The article discusses how decorators complicate the picture: a decorator may turn a function into a static method, a class method, or something else entirely, and without knowing the decorator's intent, it is impossible to decide whether an implicit self should be added.

Proposals that make self a reserved keyword or require a defself.foo(arg): syntax are rejected because they would break backward compatibility and interfere with class methods, static methods, and existing language rules.

In conclusion, while the idea of removing self aims to simplify syntax, it would introduce ambiguity, break compatibility, and complicate language features such as decorators, so the explicit self must stay.

Pythonlanguage designoopDecoratorsmethodself
Python Programming Learning Circle
Written by

Python Programming Learning Circle

A global community of Chinese Python developers offering technical articles, columns, original video tutorials, and problem sets. Topics include web full‑stack development, web scraping, data analysis, natural language processing, image processing, machine learning, automated testing, DevOps automation, and big data.

0 followers
Reader feedback

How this landed with the community

login Sign in to like

Rate this article

Was this worth your time?

Sign in to rate
Discussion

0 Comments

Thoughtful readers leave field notes, pushback, and hard-won operational detail here.