Introduction

Python uses the built-in len(obj) instead of a obj.length() method because the language favors a small set of generic operations that work across many object types. This is part of Python's data model: objects implement special methods such as __len__, and built-in functions expose those operations in a consistent public syntax.

len is a generic protocol entry point

From the user side, you write:

values = [10, 20, 30]
print(len(values))

Under the hood, Python looks for the object's __len__ implementation.

A custom class can define it:

1class Bag:
2    def __init__(self, items):
3        self._items = list(items)
4
5    def __len__(self):
6        return len(self._items)
7
8
9bag = Bag(["a", "b", "c"])
10print(len(bag))

So len() is not arbitrary. It is the public operation that maps to the underlying length protocol.

Why not obj.length()?

A method-based style would work, but Python deliberately chose a uniform built-in function interface for common protocols such as:

• 'len(obj)'
• 'iter(obj)'
• 'str(obj)'
• 'repr(obj)'

This has a few benefits:

• one public spelling across many types
• clearer support for built-in types and user-defined types alike
• separation between the protocol method and the public API

That makes code feel more consistent once you learn the pattern.

It is not just cosmetic

Using len(x) instead of x.length() means the same user-facing syntax works for:

• lists
• tuples
• strings
• dictionaries
• sets
• custom containers

That is useful because Python cares more about behavior than about inheritance from a specific container base class.

The special method still exists

Some people think len() means there is no method at all. There is one, but it is the special method __len__, not a public method named length.

Example:

text = "hello"
print(text.__len__())
print(len(text))

Both can produce the same numeric result, but idiomatic Python uses len(text).

The special method is part of the data model contract. The built-in function is the normal public interface.

This fits Python's object model more broadly

The same idea appears in other places:

• 'for x in obj maps to iteration protocol methods'
• 'obj[i] maps to item access methods'
• 'x + y maps to arithmetic special methods'

Python often prefers language-level operations and built-in functions over explicit named methods for core behaviors. len() fits that design.

Why this is useful for custom classes

If you implement __len__, your class can behave like a native container:

1class Window:
2    def __init__(self, width, height):
3        self.width = width
4        self.height = height
5
6    def __len__(self):
7        return self.width * self.height
8
9
10w = Window(3, 4)
11print(len(w))

Whether that semantic meaning is sensible is a design decision, but the mechanism is consistent with the rest of Python.

Common Pitfalls

The most common mistake is thinking len() is just a helper function layered awkwardly on top of objects. In reality, it is the intended public protocol entry point. Another is calling __len__() directly in normal code, which works but is not idiomatic. Developers coming from languages with length or size methods often assume Python lacks symmetry, but Python's symmetry is protocol-based rather than method-name-based. A subtler issue is implementing __len__ with surprising semantics in custom classes, which makes len(obj) technically valid but conceptually confusing. Finally, some people treat built-ins and special methods as unrelated, when they are really two sides of the same design.

Summary

• Python uses len(obj) as the public interface for object length.
• The underlying protocol method is __len__.
• This gives one consistent syntax across built-in and user-defined container types.
• Python often exposes core behaviors through built-ins and operators instead of ordinary public methods.
• 'obj.__len__() exists, but len(obj) is the idiomatic spelling.'
• The design is about generic protocols, not about avoiding methods entirely.