DEV Community: Bruno Teixeira Lopes

[Boost]

Bruno Teixeira Lopes — Fri, 14 Aug 2026 18:54:24 +0000

Bruno Teixeira Lopes

Aug 14

Python Data Model - Part 2: Protocols and Special Methods

#python #beginners #tutorial

19 min read

Python Data Model - Part 2: Protocols and Special Methods

Bruno Teixeira Lopes — Fri, 14 Aug 2026 18:54:19 +0000

🌐 Leia a versão em português deste artigo aqui.

1. From Part One to Language Protocols

In Part 1, we established the foundation of Python's data model: objects possess identity, type, and value; names hold references to those objects; mutability determines what changes can occur without replacing the object; and containers store references to other objects.

Now we advance another layer.

The type of an object does not merely determine what values it can represent. It also determines which operations that object supports: whether it has a size, whether it can be traversed, compared, indexed, called as a function, used in a with statement, and so forth (PYTHON SOFTWARE FOUNDATION, 2026a).

This is where special methods come in.

An important observation before we continue: in Part 1 we used memory address as a mental model for identity. More rigorously, Python guarantees that an object's identity remains stable during its existence. In CPython specifically, id(obj) corresponds to the memory address of the object; this is a detail of the reference implementation, not a language guarantee (PYTHON SOFTWARE FOUNDATION, 2026a).

The same distinction will be important when we discuss garbage collection and finalization: Python specifies the language's behavior; CPython is one implementation of that behavior.

Reference Version

The behaviors and references in this article were reviewed based on the official documentation of Python 3.14.7. CPython-specific details will be explicitly identified.

2. What Are Special Methods

In the official documentation, names like __len__, __iter__, and __add__ are called special methods. In the community, you will also commonly find the terms magic methods or dunder methods (dunder comes from double underscore because of the __name__ pattern).

They allow classes defined by us to participate in operations that are part of the language's own syntax and built-in functions.

For example:

You write	Behavior Python must resolve	Related methods
`repr(obj)`	official representation	`__repr__`
`str(obj)` / `print(obj)`	informal representation	`__str__`, with fallback to `__repr__`
`len(obj)`	size	`__len__`
`obj[key]`	subscription	`__getitem__`
`obj[key] = value`	subscription assignment	`__setitem__`
`for item in obj`	iteration	`__iter__`, `__next__`
`a == b`	equality comparison	`__eq__`
`a + b`	arithmetic operation	`__add__`, possibly `__radd__`
`obj(...)`	call	`__call__`
`with obj:`	context management	`__enter__`, `__exit__`

This table is a conceptual map, not a literal line-by-line translation of what the interpreter executes. It is precisely this difference that we need to understand.

2.1. Operation First, Method Second

Consider len().

When we write:

len([10, 20, 30])

we get:

The same happens with a string:

len("Python")
# 6

But len() does not need to possess a large sequence of checks like:

# model that DOES NOT represent how len() works

if isinstance(obj, list):
    ...
elif isinstance(obj, str):
    ...
elif isinstance(obj, tuple):
    ...

A class created by us can also participate in this behavior:

class Box:
    def __len__(self) -> int:
        return 3


box = Box()

len(box)
# 3

Box does not inherit from list, tuple, or str.

What matters is that its type offers the behavior expected by the size operation.

We can think about the path conceptually like this:

len(box)
    ↓
size operation
    ↓
corresponding protocol
    ↓
__len__

This kind of behavioral contract is what we will call a protocol throughout the article.

Python does not need to know in advance all the classes that might exist. The class informs the language which operations it supports through the appropriate special methods.

2.2. Special Method Lookup Is Different

There is, however, a fundamental nuance.

A useful first approximation is to imagine:

len(obj) ≈ type(obj).__len__(obj)

The symbol ≈ is intentional. This is a mental model, not a literal rewrite of the code executed by the interpreter.

Implicit invocations of special methods have their own lookup rules. For user-defined classes, Python looks for these methods in the type of the object, not simply in the attribute dictionary of the instance (PYTHON SOFTWARE FOUNDATION, 2026b).

See the difference:

class Box:
    def __len__(self) -> int:
        return 3


box = Box()

box.__len__ = lambda: 99

Now we have:

box.__len__()
# 99

The call above is explicit. We are accessing the __len__ attribute of the instance normally.

But:

len(box)
# 3

still uses the method defined in Box.

We can observe the approximate model:

type(box).__len__(box)
# 3

Therefore:

box.__len__()

and:

len(box)

do not have exactly the same resolution mechanism.

Important Detail

Implicit lookup of special methods generally ignores attributes defined directly on the instance and also avoids part of the normal __getattribute__ mechanism.

For this reason, so that operations like len(obj) work consistently, the corresponding special method must be defined on the class, that is, on the object's type (PYTHON SOFTWARE FOUNDATION, 2026b).

This rule explains why dunder methods should not be viewed simply as ordinary methods with strange names. They are points of integration between our types and the language's data model.

2.3. A Map of Main Groups

We do not need to memorize all existing special methods. It is more useful to group them by the behavior they allow implementing:

Category	Main Methods	Official Documentation
Creation and initialization	`__new__`, `__init__`	Basic customization
Finalization	`__del__`	object.del
Representation	`__repr__`, `__str__`, `__format__`	Basic customization
Attribute access	`__getattribute__`, `__getattr__`, `__setattr__`	Customizing attribute access
Descriptors	`__get__`, `__set__`, `__delete__`	Implementing Descriptors
Containers and sequences	`__len__`, `__getitem__`, `__setitem__`, `__contains__`	Emulating container types
Iteration	`__iter__`, `__next__`	Iterator Types
Comparisons	`__eq__`, `__lt__`, `__gt__` etc.	Basic customization
Numeric operations	`__add__`, `__mul__`, `__rmul__`, `__abs__` etc.	Emulating numeric types
Callability	`__call__`	Emulating callable objects
Context managers	`__enter__`, `__exit__`	With Statement Context Managers

The table is deliberately incomplete. The goal is not to transform this part of the series into a catalog of dunders, but to understand why they exist and how different methods form coherent behaviors.

2.4. Creation: `new` and `init`

One of the first important distinctions appears in object creation itself.

It is common to say that "__init__ creates the object", but that is not exactly what happens.

Conceptually:

Class(...)
    ↓
__new__(cls, ...)
    ↓
new instance
    ↓
__init__(instance, ...)
    ↓
object ready for the caller

__new__ is called to create and return the new instance.

__init__ receives an instance that already exists and performs its initialization or customization (PYTHON SOFTWARE FOUNDATION, 2026c).

Consider:

from typing import Self


class Connection:
    def __new__(cls, host: str) -> Self:
        print("1. __new__ created the instance")
        instance = super().__new__(cls)
        return instance

    def __init__(self, host: str) -> None:
        print("2. __init__ initialized the instance")
        self.host = host


Connection("db.local")

The result is:

1. __new__ created the instance
2. __init__ initialized the instance

Note that __new__ receives cls, not self.

This occurs because the instance is still being created. The cls argument informs which class was requested, allowing the method to return an appropriate instance even when inheritance is involved.

In the most common implementation:

super().__new__(cls)

we delegate the actual creation to the method of the base class.

It is tempting to summarize this process by saying:

"__new__ allocates memory."

But this formulation mixes different levels.

__new__ is the instance creation hook exposed by Python's data model. The low-level work necessary to produce the object, including allocation details, belongs to the runtime and the implementation used. Therefore, it is more precise to say that __new__ controls the creation and the object that will be returned, rather than treating it as synonymous with the memory allocator.

There is another important rule.

__init__ is only called automatically if __new__ returns an instance of the requested class — or of a subclass of it (PYTHON SOFTWARE FOUNDATION, 2026c).

For example:

class Factory:
    def __new__(cls) -> str:
        return "already exists"

    def __init__(self) -> None:
        print("this line will not be executed")


result = Factory()

result
# 'already exists'

type(result)
# <class 'str'>

Since __new__ returned a str, not an instance of Factory, Factory's __init__ is not executed.

__new__ gains special importance when creating subclasses of immutable types, such as int, str, and tuple. Since the immutable object cannot have its value changed after creation, changes that affect its value often need to happen during the instance's own creation (PYTHON SOFTWARE FOUNDATION, 2026c).

For ordinary classes, however, __init__ remains the customization point necessary in the great majority of cases.

2.5. Finalization: `del` Is Not a Resource Manager

At the other end of the lifecycle there is:

__del__

The documentation calls it a finalizer. The term "destructor" is used informally, but can lead to an incorrect mental model (PYTHON SOFTWARE FOUNDATION, 2026c).

To understand the problem, we need to separate some concepts.

An object can cease to be reachable by the program:

object
↓
no path accessible from the program reaches it
↓
object has become unreachable

This does not mean, as a general language rule:

unreachable = destroyed immediately

Python allows an implementation to defer garbage collection or even omit it in certain situations. What the language guarantees is that objects still reachable are not collected (PYTHON SOFTWARE FOUNDATION, 2026a).

In CPython specifically, there is a scheme based primarily on reference counting, supplemented by a garbage collector capable of detecting cycles. For this reason, many objects are freed quickly when they no longer have references. This behavior, however, is a CPython detail, not a universal Python contract (PYTHON SOFTWARE FOUNDATION, 2026a).

__del__ also has other difficulties:

it may be executed during interpreter shutdown;
other global objects on which it depends may already be unavailable;
exceptions raised within __del__ are not propagated normally;
its execution may occur in delicate circumstances, making blocking operations — such as acquiring a lock — particularly dangerous (PYTHON SOFTWARE FOUNDATION, 2026c).

This makes __del__ a poor choice to be the sole responsible party for the release of important external resources.

Examples:

files;
sockets;
locks;
database connections;
transactions;
handles provided by the operating system.

These resources typically need a deterministic moment of release.

This is precisely where with comes in. For example:

with open("data.txt", "r") as file:
    content = file.read()

The block has a well-defined point of entry and exit.

Conceptually:

with resource:
      ↓
__enter__()
      ↓
execute the block
      ↓
__exit__()

Even when an exception occurs within the block, the context manager protocol provides an appropriate point to execute exit logic (PYTHON SOFTWARE FOUNDATION, 2026d).

This difference is fundamental:

__del__
→ finalization tied to the object's lifecycle

with / context manager
→ explicit management of a resource's lifecycle

For resources that need to be released at a predictable moment, prefer context managers or explicit APIs, do not rely exclusively on __del__.

2.6. Arithmetic: `NotImplemented` and Reflected Operations

Special methods also allow objects to participate in operators.

Some examples:

Operation	Method
`a + b`	`__add__`
`a - b`	`__sub__`
`a * b`	`__mul__`
`a / b`	`__truediv__`
`a ** b`	`__pow__`
`-a`	`__neg__`
`abs(a)`	`__abs__`

But implementing operators correctly requires more than simply writing the calculation.

Consider a duration stored in minutes:

from __future__ import annotations

from dataclasses import dataclass
from types import NotImplementedType


@dataclass(frozen=True)
class Duration:
    minutes: int

    def __add__(self, other: object) -> Duration | NotImplementedType:
        if not isinstance(other, Duration):
            return NotImplemented

        return Duration(self.minutes + other.minutes)

    def __mul__(self, factor: object) -> Duration | NotImplementedType:
        if not isinstance(factor, int):
            return NotImplemented

        return Duration(self.minutes * factor)

    __rmul__ = __mul__

    def __str__(self) -> str:
        hours, minutes = divmod(self.minutes, 60)
        return f"{hours}h{minutes:02d}"

Now:

Duration(90) + Duration(45)
# Duration(minutes=135)

3 * Duration(50)
# Duration(minutes=150)

print(Duration(135))
# 2h15

But:

Duration(90) + 45
# TypeError

The central point is in this line:

return NotImplemented

NotImplemented is a special singleton object used by numeric methods and comparisons when that method does not implement the operation for the pair of operands received (PYTHON SOFTWARE FOUNDATION, 2026e).

This is different from saying:

"Never raise an exception inside an operator."

This rule would be too broad.

If the problem is:

"My __add__ does not know how to add Duration with this type of object."

then NotImplemented is normally the appropriate response.

If the operation is supported, but a received value violates some legitimate domain rule, an appropriate exception can still make sense.

And Why Does `rmul` Exist?

Consider:

3 * Duration(50)

In this specific case, int is on the left.

For this pair of types:

int.__mul__(3, Duration(50))

does not know how to produce a result and returns:

NotImplemented

This allows Python to try the reflected form of the operation on the other operand:

Duration.__rmul__(Duration(50), 3)

Our method accepts the integer factor and returns:

Duration(150)

A simplified model is:

a * b
  ↓
appropriate method supports the operation?
  ↓ no
NotImplemented
  ↓
reflected attempt
  ↓
supports?
  ├─ yes → result
  └─ no → TypeError

There is an important nuance: this is not always a rigid rule of "left side first, right side second".

When operands have different types and the type on the right is a subclass of the type on the left, the reflected method of the subclass may receive priority. This allows the more specific implementation to have the opportunity to control the result (PYTHON SOFTWARE FOUNDATION, 2026f).

For int and Duration, however, there is no such inheritance relationship, and the flow described above correctly represents:

3 * Duration(50)

In this example:

__rmul__ = __mul__

is valid because multiplying a duration by a scalar has the same logic regardless of the syntactic order.

This should not be copied automatically to any operator: operations like subtraction and division are not commutative.

NotImplemented is NOT NotImplementedError

NotImplemented is a returned value by protocols like numeric operations and comparisons to indicate that this combination of operands is not supported.

NotImplementedError is an exception, normally used when an API or implementation deliberately leaves a particular operation unimplemented.

The official documentation makes explicit that the two are not interchangeable (PYTHON SOFTWARE FOUNDATION, 2026g).

2.7. Attributes: `getattr` and `setattr`

The access:

obj.name

also goes through the data model.

Before reaching __getattr__, Python performs the normal attribute lookup mechanism, which involves the instance, its class, the class hierarchy, and, when applicable, descriptors.

Only when this lookup ends in AttributeError does __getattr__ function as a fallback (PYTHON SOFTWARE FOUNDATION, 2026h).

Conceptually:

obj.name
   ↓
normal attribute lookup
   ↓
found?
├─ yes → returns the value
└─ no
    ↓
__getattr__(obj, "name")

This is important because __getattr__ does not participate in every attribute read.

There is another method:

__getattribute__

that participates unconditionally in the access to instance attributes and allows controlling the process much more broadly.

We will not delve into it here, but the distinction is important:

__getattribute__
→ participates in every normal read

__getattr__
→ fallback when lookup fails

Now we can build a read-only configuration:

class Config:
    _data: dict[str, str]

    def __init__(self, **values: str) -> None:
        object.__setattr__(self, "_data", values)

    def __getattr__(self, name: str) -> str:
        try:
            return self._data[name]
        except KeyError:
            raise AttributeError(f"'{name}' does not exist in config") from None

    def __setattr__(self, name: str, value: str) -> None:
        raise AttributeError("Config is read-only")

Usage:

cfg = Config(
    host="localhost",
    port="5432",
)

cfg.host
# 'localhost'

cfg.port
# '5432'

host and port do not exist as normal attributes of the instance.

When:

cfg.host

is not found by normal lookup, __getattr__ receives:

name == "host"

and looks up the information in:

self._data

Why Does `_data` Start With an Underscore?

A single leading underscore is a internal use convention used to communicate:

"This name is part of the internal implementation and should not be treated as public API."

It does not create true access control.

It is still possible to write:

cfg._data

Python does not block this access.

This is different from:

__data

Two leading underscores activate a mechanism called name mangling, which transforms the name internally to reduce accidental collisions, mainly in inheritance scenarios.

For our example, _data communicates exactly what we want: it is a non-public implementation detail.

And Why Do We Use `object.setattr`?

Now observe:

def __setattr__(self, name: str, value: str) -> None:
    raise AttributeError("Config is read-only")

__setattr__ is called when we attempt to perform an attribute assignment (PYTHON SOFTWARE FOUNDATION, 2026h).

Therefore:

cfg.host = "other"

results in:

AttributeError: Config is read-only

The same would happen inside __init__ itself if we wrote:

self._data = values

This instruction is also an attribute assignment:

self._data = values
        ↓
self.__setattr__("_data", values)
        ↓
AttributeError

For this reason we do:

object.__setattr__(self, "_data", values)

We are not "turning off" the entire attribute model. We are calling directly the implementation of the base class and, with that, avoiding our custom Config.__setattr__.

The documentation itself recommends this pattern when a __setattr__ needs to perform an actual assignment on the instance (PYTHON SOFTWARE FOUNDATION, 2026h).

Recursion Pitfall

An implementation like:

def __setattr__(self, name, value):
    self.name = value

would call __setattr__ again, which would execute another assignment, which would call __setattr__ again...

When it is necessary to delegate to the base behavior, explicitly use object.__setattr__.

Why Transform `KeyError` Into `AttributeError`?

Inside __getattr__ we have:

try:
    return self._data[name]
except KeyError:
    raise AttributeError(f"'{name}' does not exist in config") from None

The dictionary expresses absence through:

KeyError

But we are implementing attribute access.

In this protocol, absence must be communicated through:

AttributeError

This is important because other Python mechanisms also depend on this exception to determine if an attribute exists. from None suppresses the automatic display of the context with the previous KeyError in the traceback, leaving visible only the exception that correctly represents the class's public abstraction (PYTHON SOFTWARE FOUNDATION, 2026j). Without from None, Python would also show the context of the previous exception.

The Next Layer: Descriptors

Up to this point we have customized operations directly on the instance.

Descriptors solve another problem: they allow an attribute stored on the class to control what happens when it is read, written, or removed.

The protocol uses:

__get__
__set__
__delete__

Conceptually:

obj.attribute
    ↓
Python finds a descriptor object on the class
    ↓
__get__(...)

or, during write:

obj.attribute = value
        ↓
__set__(...)

This mechanism is behind fundamental language features, including property, bound methods, and classmethod (PYTHON SOFTWARE FOUNDATION, 2026k).

For example:

class Person:
    def __init__(self, name: str) -> None:
        self._name = name

    @property
    def name(self) -> str:
        return self._name

The object created by property participates in the descriptors protocol.

We do not need to delve into the entire mechanics now. The important point is to realize that attribute access is also extensible through data model protocols.

2.8. Protocols Are More Than Method Names

We can now refine the definition.

A protocol does not merely mean:

"There is a method with a particular name."

It also involves the semantic contract expected of that method.

For example:

__len__ should represent size and return a non-negative integer;
__getitem__ of a sequence should use appropriate exceptions for invalid indices;
an iterator should signal its end through StopIteration;
__eq__ can return NotImplemented for operands it does not know how to compare;
__hash__ must remain coherent with equality.

It is possible to write a method with the correct name and still implement the protocol poorly.

For this reason, we are going to start by applying this principle to a single class, which will continue evolving in the next part of the series.

Our base will be an N-dimensional vector:

class Vector:
    def __init__(self, *components: float) -> None:
        self._components = list(components)

Now we can create:

Vector(3, 4)
Vector(1, 2, 3)
Vector(2, 5, 8, 13)

The components are stored in an internal collection:

_components

The Vector in this article will have two important design decisions:

The values of the components can be changed;
The number of components will remain fixed after construction.

Therefore, it will be mutable as to values, but will not offer operations that add or remove dimensions.

For didactic purposes we will also allow:

Vector()

representing a vector without components. A real domain might reject this construction if it did not make sense.

From here on, each new method must respect these same decisions. In this part, we will start with textual representation; in the next, we will continue evolving the same Vector through the protocols of size, indexing, iteration, and comparison.

3. Representation: `repr` and `str`

Let us start with the most visible behavior.

Without customized __repr__ or __str__:

v = Vector(3, 4)

v

in CPython normally produces something like:

<__main__.Vector object at 0x...>

The exact format of this default representation should not be treated as part of our class's contract.

What we want to answer is:

How should a Vector represent itself textually?

Python offers two main methods for this.

Aspect	`__repr__`	`__str__`
Role in documentation	official representation	informal or easily printable representation
Common purpose	rich in information and unambiguous	convenient and readable
Typical use	REPL, debugging, technical logs	presentation for human reading
Triggered by	`repr(v)`, `f"{v!r}"`	`str(v)`, `print(v)`, `f"{v}"`, `f"{v!s}"`

The "developer versus end user" distinction can be a useful analogy, but it is not the normative definition.

The documentation defines __repr__ as responsible for the "official" representation and recommends, when possible, a form resembling a Python expression capable of recreating an equivalent object. __str__, on the other hand, can produce a more convenient or concise representation (PYTHON SOFTWARE FOUNDATION, 2026c).

Let us start with __repr__:

class Vector:
    # ... __init__ from the previous section

    def __repr__(self) -> str:
        components = ", ".join(
            repr(component)
            for component in self._components
        )

        return f"Vector({components})"

Now:

v = Vector(3, 4)

repr(v)
# 'Vector(3, 4)'

v
# Vector(3, 4)

And for different dimensions:

Vector(1, 2, 3)
# Vector(1, 2, 3)

Vector()
# Vector()

The representation accompanies the data actually stored. There is no longer any hardcoded assumption that a vector must have only x and y.

Now we add a more compact form for __str__:

class Vector:
    # ...

    def __str__(self) -> str:
        components = ", ".join(
            str(component)
            for component in self._components
        )

        return f"({components})"

With that:

v = Vector(3, 4)

repr(v)
# 'Vector(3, 4)'

str(v)
# '(3, 4)'

print(v)
# (3, 4)

f"{v}"
# '(3, 4)'

f"{v!s}"
# '(3, 4)'

f"{v!r}"
# 'Vector(3, 4)'

The Fallback of `str`

There is still an important relationship between the two methods.

If we define __repr__, but not __str__, the official representation is also used when an informal representation is needed (PYTHON SOFTWARE FOUNDATION, 2026c).

For this reason, a class with only:

def __repr__(self) -> str:
    return "..."

already improves both:

repr(obj)

and:

str(obj)
print(obj)

The opposite does not have the same relationship: implementing only __str__ does not substitute for the need for an appropriate official representation.

And Containers?

Observe:

v = Vector(3, 4)

[v]
# [Vector(3, 4)]

Even though:

str(v)

produces:

(3, 4)

a list's representation uses the official representation of its elements.

This is useful for debugging:

vectors = [
    Vector(1, 2),
    Vector(3, 4),
]

vectors
# [Vector(1, 2), Vector(3, 4)]

The container can clearly show which objects it contains, without depending on the more informal version produced by __str__.

4. Conclusion

Throughout this part, we moved beyond the idea that methods like __len__, __repr__, or __add__ are simply special names that Python calls automatically. The broader point is that they are points of integration between our types and the language's protocols.

When we write:

len(obj)

or:

a * b

or even:

obj.name

we are not merely calling isolated functions or operators. We are triggering behaviors defined by the data model, each with its own resolution rules and its own contracts.

For this reason, throughout the article, we saw that:

len(obj) is not equivalent to an ordinary call to obj.__len__();
__new__ and __init__ participate in different moments of instance creation;
__del__ should not be confused with deterministic resource management;
NotImplemented is part of the negotiation between operands;
__getattr__ functions as a fallback in attribute access;
descriptors form another protocol behind mechanisms like property;
__repr__ and __str__ represent different contracts for the textual representation of an object.

These examples also show why implementing a dunder method does not merely mean using the correct name. To properly participate in a protocol, the class must respect the expected semantics of that operation.

The Vector introduced at the end of this part is our point of continuity.

So far, we have defined how it stores its components and how it should represent itself:

Vector(3, 4)

or, in its informal form:

(3, 4)

In the next part, the question changes.

Instead of observing protocols in isolation, we will see what happens when several of them need to coexist in the same type. We will decide, among other things:

len(v)

should represent what?

How should:

v[0]
v[-1]
v[1:3]

behave?

What makes:

for component in v:
    ...

possible?

And if the Vector is mutable, how does that affect:

v1 == v2

and its ability to be used in a set or as a dict key?

It is at this point that protocols cease to seem like independent features and begin to reveal something even more important about the data model: behavioral decisions in one part of the class can impose consequences on several others.

In Part 3, we will continue precisely from there, evolving the same Vector through the protocols of size, indexing, iteration, equality, and hashing.

References

PYTHON SOFTWARE FOUNDATION. 3.1. Objects, values and types. In: Python 3.14.7 documentation. [S. l.]: Python Software Foundation, 2026a. Available at: https://docs.python.org/3.14/reference/datamodel.html#objects-values-and-types. Accessed on: Aug. 14, 2026.

PYTHON SOFTWARE FOUNDATION. 3.3.13. Special method lookup. In: Python 3.14.7 documentation. [S. l.]: Python Software Foundation, 2026b. Available at: https://docs.python.org/3.14/reference/datamodel.html#special-method-lookup. Accessed on: Aug. 14, 2026.

PYTHON SOFTWARE FOUNDATION. 3.3.1. Basic customization. In: Python 3.14.7 documentation. [S. l.]: Python Software Foundation, 2026c. Available at: https://docs.python.org/3.14/reference/datamodel.html#basic-customization. Accessed on: Aug. 14, 2026.

PYTHON SOFTWARE FOUNDATION. 3.3.9. With Statement Context Managers. In: Python 3.14.7 documentation. [S. l.]: Python Software Foundation, 2026d. Available at: https://docs.python.org/3.14/reference/datamodel.html#with-statement-context-managers. Accessed on: Aug. 14, 2026.

PYTHON SOFTWARE FOUNDATION. 3.2.2. NotImplemented. In: Python 3.14.7 documentation. [S. l.]: Python Software Foundation, 2026e. Available at: https://docs.python.org/3.14/reference/datamodel.html#notimplemented. Accessed on: Aug. 14, 2026.

PYTHON SOFTWARE FOUNDATION. 3.3.8. Emulating numeric types. In: Python 3.14.7 documentation. [S. l.]: Python Software Foundation, 2026f. Available at: https://docs.python.org/3.14/reference/datamodel.html#emulating-numeric-types. Accessed on: Aug. 14, 2026.

PYTHON SOFTWARE FOUNDATION. NotImplementedError. In: Built-in Exceptions — Python 3.14.7 documentation. [S. l.]: Python Software Foundation, 2026g. Available at: https://docs.python.org/3.14/library/exceptions.html#NotImplementedError. Accessed on: Aug. 14, 2026.

PYTHON SOFTWARE FOUNDATION. 3.3.2. Customizing attribute access. In: Python 3.14.7 documentation. [S. l.]: Python Software Foundation, 2026h. Available at: https://docs.python.org/3.14/reference/datamodel.html#customizing-attribute-access. Accessed on: Aug. 14, 2026.

PYTHON SOFTWARE FOUNDATION. 9.6. Private Variables. In: The Python Tutorial — Python 3.14.7 documentation. [S. l.]: Python Software Foundation, 2026i. Available at: https://docs.python.org/3.14/tutorial/classes.html#private-variables. Accessed on: Aug. 14, 2026.

PYTHON SOFTWARE FOUNDATION. 7.8. The raise statement. In: Python Language Reference — Python 3.14.7 documentation. [S. l.]: Python Software Foundation, 2026j. Available at: https://docs.python.org/3.14/reference/simple_stmts.html#the-raise-statement. Accessed on: Aug. 14, 2026.

PYTHON SOFTWARE FOUNDATION. Descriptor Guide — Descriptor protocol. In: Python 3.14.7 documentation. [S. l.]: Python Software Foundation, 2026k. Available at: https://docs.python.org/3.14/howto/descriptor.html#descriptor-protocol. Accessed on: Aug. 14, 2026.

Editorial note: This article was developed and reviewed by the author with AI assistance during research, technical auditing, and editorial review. Technical claims were verified against the official sources listed in the references.

Quem puder dar uma força na parte 2 da série, to aprendendo e curtindo muito produzir estes conteúdos!

Bruno Teixeira Lopes — Fri, 14 Aug 2026 18:48:41 +0000

Bruno Teixeira Lopes

Aug 14

Modelo de Dados Python - Parte 2: Protocolos e métodos especiais

#python #tutorial #beginners

20 min read

Modelo de Dados Python - Parte 2: Protocolos e métodos especiais

Bruno Teixeira Lopes — Fri, 14 Aug 2026 18:47:41 +0000

🌐 Read this article in English here.

1. Da primeira parte aos protocolos da linguagem

Na Parte 1, construímos a base do modelo de dados do Python: objetos possuem identidade, tipo e valor; nomes guardam referências para esses objetos; mutabilidade determina quais mudanças podem acontecer sem substituir o objeto; e containers armazenam referências para outros objetos.

Agora vamos avançar uma camada.

O tipo de um objeto não determina apenas quais valores ele pode representar. Ele também determina quais operações aquele objeto suporta: se possui tamanho, se pode ser percorrido, comparado, indexado, chamado como função, usado em um with e assim por diante (PYTHON SOFTWARE FOUNDATION, 2026a).

É aqui que entram os métodos especiais.

Uma observação importante antes de continuar: na Parte 1 usamos o endereço de memória como modelo mental para identidade. De forma mais rigorosa, Python garante que a identidade de um objeto é estável durante sua existência. No CPython, especificamente, id(obj) corresponde ao endereço de memória do objeto; isso é um detalhe da implementação de referência, não uma garantia da linguagem (PYTHON SOFTWARE FOUNDATION, 2026a).

A mesma distinção será importante quando falarmos sobre garbage collection e finalização: Python especifica o comportamento da linguagem; CPython é uma implementação desse comportamento.

Versão de referência

Os comportamentos e referências deste artigo foram revisados com base na documentação oficial do Python 3.14.7. Detalhes exclusivos do CPython serão identificados explicitamente.

2. O que são métodos especiais

Na documentação oficial, nomes como __len__, __iter__ e __add__ são chamados de special methods, ou métodos especiais, na comunidade também é comum encontrar os termos métodos mágicos ou dunder methods (dunder vem de double underscore por causa do padrão __nome__).

Eles permitem que classes definidas por nós participem de operações que fazem parte da própria sintaxe e das funções embutidas da linguagem.

Por exemplo:

Você escreve	Comportamento que Python precisa resolver	Métodos relacionados
`repr(obj)`	representação oficial	`__repr__`
`str(obj)` / `print(obj)`	representação informal	`__str__`, com fallback para `__repr__`
`len(obj)`	tamanho	`__len__`
`obj[chave]`	subscrição	`__getitem__`
`obj[chave] = valor`	atribuição por subscrição	`__setitem__`
`for item in obj`	iteração	`__iter__`, `__next__`
`a == b`	comparação de igualdade	`__eq__`
`a + b`	operação aritmética	`__add__`, possivelmente `__radd__`
`obj(...)`	chamada	`__call__`
`with obj:`	gerenciamento de contexto	`__enter__`, `__exit__`

Essa tabela é um mapa conceitual, não uma tradução literal linha por linha do que o interpretador executa. É justamente essa diferença que precisamos entender.

2.1. Operação primeiro, método depois

Considere len().

Quando escrevemos:

len([10, 20, 30])

obtemos:

O mesmo acontece com uma string:

len("Python")
# 6

Mas len() não precisa possuir uma grande sequência de verificações como:

# modelo que NÃO representa o funcionamento de len()

if isinstance(obj, list):
    ...
elif isinstance(obj, str):
    ...
elif isinstance(obj, tuple):
    ...

Uma classe criada por nós também pode participar desse comportamento:

class Caixa:
    def __len__(self) -> int:
        return 3


caixa = Caixa()

len(caixa)
# 3

Caixa não herda de list, tuple ou str.

O que importa é que seu tipo oferece o comportamento esperado pela operação de tamanho.

Podemos pensar no caminho conceitualmente assim:

len(caixa)
     ↓
operação de tamanho
     ↓
protocolo correspondente
     ↓
__len__

É esse tipo de contrato comportamental que chamaremos de protocolo ao longo do artigo.

Python não precisa conhecer antecipadamente todas as classes que poderão existir. A classe informa à linguagem quais operações suporta através dos métodos especiais apropriados.

2.2. O lookup de métodos especiais é diferente

Existe, porém, uma nuance fundamental.

Uma primeira aproximação útil é imaginar:

len(obj) ≈ type(obj).__len__(obj)

O símbolo ≈ é proposital. Isso é um modelo mental, e não uma reescrita literal do código executado pelo interpretador.

Invocações implícitas de métodos especiais possuem regras próprias de lookup. Para classes definidas pelo usuário, Python procura esses métodos no tipo do objeto, e não simplesmente no dicionário de atributos da instância (PYTHON SOFTWARE FOUNDATION, 2026b).

Veja a diferença:

class Caixa:
    def __len__(self) -> int:
        return 3


caixa = Caixa()

caixa.__len__ = lambda: 99

Agora temos:

caixa.__len__()
# 99

A chamada acima é explícita. Estamos acessando normalmente o atributo __len__ da instância.

Mas:

len(caixa)
# 3

continua usando o método definido em Caixa.

Podemos observar o modelo aproximado:

type(caixa).__len__(caixa)
# 3

Portanto:

caixa.__len__()

len(caixa)

não possuem exatamente o mesmo mecanismo de resolução.

Detalhe importante

O lookup implícito de métodos especiais geralmente ignora atributos definidos diretamente na instância e também evita parte do mecanismo normal de __getattribute__.

Por isso, para que operações como len(obj) funcionem consistentemente, o método especial correspondente deve ser definido na classe, isto é, no tipo do objeto (PYTHON SOFTWARE FOUNDATION, 2026b).

Essa regra explica por que dunder methods não devem ser encarados simplesmente como métodos comuns com nomes estranhos. Eles são pontos de integração entre nossos tipos e o modelo de dados da linguagem.

2.3. Um mapa dos principais grupos

Não precisamos decorar todos os special methods existentes. É mais útil agrupá-los pelo comportamento que permitem implementar:

Categoria	Métodos principais	Documentação oficial
Criação e inicialização	`__new__`, `__init__`	Basic customization
Finalização	`__del__`	object.del
Representação	`__repr__`, `__str__`, `__format__`	Basic customization
Acesso a atributos	`__getattribute__`, `__getattr__`, `__setattr__`	Customizing attribute access
Descritores	`__get__`, `__set__`, `__delete__`	Implementing Descriptors
Containers e sequências	`__len__`, `__getitem__`, `__setitem__`, `__contains__`	Emulating container types
Iteração	`__iter__`, `__next__`	Iterator Types
Comparações	`__eq__`, `__lt__`, `__gt__` etc.	Basic customization
Operações numéricas	`__add__`, `__mul__`, `__rmul__`, `__abs__` etc.	Emulating numeric types
Chamabilidade	`__call__`	Emulating callable objects
Gerenciadores de contexto	`__enter__`, `__exit__`	With Statement Context Managers

A tabela é deliberadamente incompleta. O objetivo não é transformar esta parte da série em um catálogo de dunders, mas entender por que eles existem e como diferentes métodos formam comportamentos coerentes.

2.4. Criação: `new` e `init`

Uma das primeiras distinções importantes aparece na própria criação de objetos.

É comum dizer que "__init__ cria o objeto", mas isso não é exatamente o que acontece.

Conceitualmente:

Classe(...)
    ↓
__new__(cls, ...)
    ↓
nova instância
    ↓
__init__(instância, ...)
    ↓
objeto pronto para o chamador

__new__ é chamado para criar e retornar a nova instância.

__init__ recebe uma instância que já existe e realiza sua inicialização ou customização (PYTHON SOFTWARE FOUNDATION, 2026c).

Considere:

from typing import Self


class Conexao:
    def __new__(cls, host: str) -> Self:
        print("1. __new__ criou a instância")
        instancia = super().__new__(cls)
        return instancia

    def __init__(self, host: str) -> None:
        print("2. __init__ inicializou a instância")
        self.host = host


Conexao("db.local")

O resultado é:

1. __new__ criou a instância
2. __init__ inicializou a instância

Observe que __new__ recebe cls, e não self.

Isso ocorre porque a instância ainda está sendo criada. O argumento cls informa qual classe foi solicitada, permitindo que o método devolva uma instância apropriada inclusive quando herança está envolvida.

Na implementação mais comum:

super().__new__(cls)

delegamos a criação efetiva para o método da classe base.

É tentador resumir esse processo dizendo:

"__new__ aloca memória."

Mas essa formulação mistura níveis diferentes.

__new__ é o hook de criação de instâncias exposto pelo modelo de dados Python. O trabalho de baixo nível necessário para produzir o objeto, incluindo detalhes de alocação, pertence ao runtime e à implementação utilizada. Portanto, é mais preciso dizer que __new__ controla a criação e o objeto que será retornado, e não tratá-lo como sinônimo do allocator de memória.

Existe outra regra importante.

__init__ só é chamado automaticamente se __new__ retornar uma instância da classe solicitada — ou de uma subclasse dela (PYTHON SOFTWARE FOUNDATION, 2026c).

Por exemplo:

class Fabrica:
    def __new__(cls) -> str:
        return "já existe"

    def __init__(self) -> None:
        print("esta linha não será executada")


resultado = Fabrica()

resultado
# 'já existe'

type(resultado)
# <class 'str'>

Como __new__ retornou uma str, e não uma instância de Fabrica, o __init__ de Fabrica não é executado.

__new__ ganha importância especial ao criar subclasses de tipos imutáveis, como int, str e tuple. Como o objeto imutável não pode ter seu valor alterado depois de criado, mudanças que afetam seu valor frequentemente precisam acontecer durante a própria criação da instância (PYTHON SOFTWARE FOUNDATION, 2026c).

Para classes comuns, entretanto, __init__ continua sendo o ponto de customização necessário na grande maioria dos casos.

2.5. Finalização: `del` não é um gerenciador de recursos

No outro extremo do ciclo de vida existe:

__del__

A documentação o chama de finalizer. O termo “destrutor” é usado informalmente, mas pode induzir a um modelo mental incorreto (PYTHON SOFTWARE FOUNDATION, 2026c).

Para entender o problema, precisamos separar alguns conceitos.

Um objeto pode deixar de ser alcançável pelo programa:

objeto
↓
nenhum caminho acessível do programa chega até ele
↓
objeto tornou-se inalcançável

Isso não significa, como regra geral da linguagem:

inalcançável = destruído imediatamente

Python permite que uma implementação adie a coleta de lixo ou até deixe de realizá-la em determinadas situações. O que a linguagem garante é que objetos ainda alcançáveis não sejam coletados (PYTHON SOFTWARE FOUNDATION, 2026a).

No CPython, especificamente, existe um esquema baseado principalmente em contagem de referências, complementado por um garbage collector capaz de detectar ciclos. Por isso muitos objetos são liberados rapidamente quando deixam de possuir referências. Esse comportamento, porém, é um detalhe do CPython, não um contrato universal de Python (PYTHON SOFTWARE FOUNDATION, 2026a).

__del__ também possui outras dificuldades:

pode ser executado durante o encerramento do interpretador;
outros objetos globais dos quais ele depende podem já estar indisponíveis;
exceções levantadas dentro de __del__ não são propagadas normalmente;
sua execução pode ocorrer em circunstâncias delicadas, tornando operações bloqueantes — como adquirir um lock — particularmente perigosas (PYTHON SOFTWARE FOUNDATION, 2026c).

Isso torna __del__ uma escolha ruim para ser o único responsável pela liberação de recursos externos importantes.

Exemplos:

arquivos;
sockets;
locks;
conexões com bancos de dados;
transações;
handles fornecidos pelo sistema operacional.

Esses recursos normalmente precisam de um momento determinístico de liberação.

É exatamente aqui que entra with. Por exemplo:

with open("dados.txt", "r") as arquivo:
    conteudo = arquivo.read()

O bloco possui um ponto bem definido de entrada e saída.

Conceitualmente:

with recurso:
      ↓
__enter__()
      ↓
executa o bloco
      ↓
__exit__()

Mesmo quando uma exceção ocorre dentro do bloco, o protocolo de context manager fornece um ponto apropriado para executar a lógica de saída (PYTHON SOFTWARE FOUNDATION, 2026d).

Essa diferença é fundamental:

__del__
→ finalização ligada ao ciclo de vida do objeto

with / context manager
→ gerenciamento explícito do ciclo de vida de um recurso

Para recursos que precisam ser liberados em um momento previsível, prefira context managers ou APIs explícitas, não dependa exclusivamente de __del__.

2.6. Aritmética: `NotImplemented` e operações refletidas

Métodos especiais também permitem que objetos participem de operadores.

Alguns exemplos:

Operação	Método
`a + b`	`__add__`
`a - b`	`__sub__`
`a * b`	`__mul__`
`a / b`	`__truediv__`
`a ** b`	`__pow__`
`-a`	`__neg__`
`abs(a)`	`__abs__`

Mas implementar operadores corretamente exige mais do que simplesmente escrever o cálculo.

Considere uma duração armazenada em minutos:

from __future__ import annotations

from dataclasses import dataclass
from types import NotImplementedType


@dataclass(frozen=True)
class Duracao:
    minutos: int

    def __add__(self, outra: object) -> Duracao | NotImplementedType:
        if not isinstance(outra, Duracao):
            return NotImplemented

        return Duracao(self.minutos + outra.minutos)

    def __mul__(self, fator: object) -> Duracao | NotImplementedType:
        if not isinstance(fator, int):
            return NotImplemented

        return Duracao(self.minutos * fator)

    __rmul__ = __mul__

    def __str__(self) -> str:
        horas, minutos = divmod(self.minutos, 60)
        return f"{horas}h{minutos:02d}"

Agora:

Duracao(90) + Duracao(45)
# Duracao(minutos=135)

3 * Duracao(50)
# Duracao(minutos=150)

print(Duracao(135))
# 2h15

Mas:

Duracao(90) + 45
# TypeError

O ponto central está nesta linha:

return NotImplemented

NotImplemented é um objeto singleton especial utilizado pelos métodos numéricos e pelas comparações quando aquele método não implementa a operação para o par de operandos recebido (PYTHON SOFTWARE FOUNDATION, 2026e).

Isso é diferente de dizer:

“Nunca levante uma exceção dentro de um operador.”

Essa regra seria excessivamente ampla.

Se o problema é:

“Meu __add__ não sabe somar Duracao com esse tipo de objeto.”

então NotImplemented é normalmente a resposta apropriada.

Se a operação é suportada, mas um valor recebido viola alguma regra legítima do domínio, uma exceção adequada ainda pode fazer sentido.

E por que existe `rmul`?

Considere:

3 * Duracao(50)

Neste caso específico, int está à esquerda.

Para esse par de tipos:

int.__mul__(3, Duracao(50))

não sabe produzir um resultado e devolve:

NotImplemented

Isso permite que Python tente a forma refletida da operação no outro operando:

Duracao.__rmul__(Duracao(50), 3)

Nosso método aceita o fator inteiro e devolve:

Duracao(150)

Um modelo simplificado é:

a * b
  ↓
método apropriado suporta a operação?
  ↓ não
NotImplemented
  ↓
tentativa refletida
  ↓
suporta?
  ├─ sim → resultado
  └─ não → TypeError

Há uma nuance importante: essa não é sempre uma regra rígida de “lado esquerdo primeiro, lado direito depois”.

Quando os operandos possuem tipos diferentes e o tipo da direita é uma subclasse do tipo da esquerda, o método refletido da subclasse pode receber prioridade. Isso permite que a implementação mais específica tenha a oportunidade de controlar o resultado (PYTHON SOFTWARE FOUNDATION, 2026f).

Para int e Duracao, entretanto, não existe essa relação de herança, e o fluxo descrito acima representa corretamente:

3 * Duracao(50)

Neste exemplo:

__rmul__ = __mul__

é válido porque multiplicar uma duração por um escalar possui a mesma lógica independentemente da ordem sintática.

Isso não deve ser copiado automaticamente para qualquer operador: operações como subtração e divisão não são comutativas.

NotImplemented não é NotImplementedError

NotImplemented é um valor retornado por protocolos como operações numéricas e comparações para indicar que aquela combinação de operandos não é suportada.

NotImplementedError é uma exceção, normalmente utilizada quando uma API ou implementação deliberadamente deixa determinada operação sem implementação.

A documentação oficial explicita que os dois não são intercambiáveis (PYTHON SOFTWARE FOUNDATION, 2026g).

2.7. Atributos: `getattr` e `setattr`

O acesso:

obj.nome

também passa pelo modelo de dados.

Antes de chegar a __getattr__, Python realiza o mecanismo normal de busca de atributos, que envolve a instância, sua classe, a hierarquia de classes e, quando aplicável, descriptors.

Só quando essa busca termina em AttributeError, __getattr__ funciona como fallback (PYTHON SOFTWARE FOUNDATION, 2026h).

Conceitualmente:

obj.nome
   ↓
busca normal de atributos
   ↓
encontrou?
├─ sim → devolve o valor
└─ não
    ↓
__getattr__(obj, "nome")

Isso é importante porque __getattr__ não participa de toda leitura de atributos.

Existe outro método:

__getattribute__

que participa incondicionalmente do acesso a atributos de instâncias e permite controlar o processo de forma muito mais ampla.

Não vamos aprofundá-lo aqui, mas a distinção é importante:

__getattribute__
→ participa de toda leitura normal

__getattr__
→ fallback quando a busca falha

Agora podemos construir uma configuração somente leitura:

class Config:
    _dados: dict[str, str]

    def __init__(self, **valores: str) -> None:
        object.__setattr__(self, "_dados", valores)

    def __getattr__(self, nome: str) -> str:
        try:
            return self._dados[nome]
        except KeyError:
            raise AttributeError(f"'{nome}' não existe na configuração") from None

    def __setattr__(self, nome: str, valor: str) -> None:
        raise AttributeError("Config é somente leitura")

Uso:

cfg = Config(
    host="localhost",
    porta="5432",
)

cfg.host
# 'localhost'

cfg.porta
# '5432'

host e porta não existem como atributos normais da instância.

Quando:

cfg.host

não é encontrado pela busca normal, __getattr__ recebe:

nome == "host"

e procura a informação em:

self._dados

Por que `_dados` começa com underscore?

Um único underscore inicial é uma convenção de uso interno usada para comunicar:

“Este nome faz parte da implementação interna e não deveria ser tratado como API pública.”

Ele não cria verdadeiro controle de acesso.

Ainda é possível escrever:

cfg._dados

Python não bloqueia esse acesso.

Isso é diferente de:

__dados

Dois underscores iniciais ativam um mecanismo chamado name mangling, que transforma o nome internamente para reduzir colisões acidentais, principalmente em cenários de herança.

Para nosso exemplo, _dados comunica exatamente o que queremos: trata-se de um detalhe não público da implementação.

E por que usamos `object.setattr`?

Agora observe:

def __setattr__(self, nome: str, valor: str) -> None:
    raise AttributeError("Config é somente leitura")

__setattr__ é chamado quando tentamos realizar uma atribuição de atributo (PYTHON SOFTWARE FOUNDATION, 2026h).

Portanto:

cfg.host = "outro"

resulta em:

AttributeError: Config é somente leitura

O mesmo aconteceria dentro do próprio __init__ se escrevêssemos:

self._dados = valores

Essa instrução também é uma atribuição de atributo:

self._dados = valores
        ↓
self.__setattr__("_dados", valores)
        ↓
AttributeError

Por isso fazemos:

object.__setattr__(self, "_dados", valores)

Não estamos “desligando” o modelo de atributos inteiro. Estamos chamando diretamente a implementação da classe base e, com isso, evitando nosso Config.__setattr__ customizado.

A própria documentação recomenda esse padrão quando um __setattr__ precisa realizar uma atribuição real na instância (PYTHON SOFTWARE FOUNDATION, 2026h).

Armadilha de recursão

Uma implementação como:

def __setattr__(self, nome, valor):
    self.nome = valor

chamaria novamente __setattr__, que executaria outra atribuição, que chamaria __setattr__ outra vez...

Quando é necessário delegar ao comportamento base, use explicitamente object.__setattr__.

Por que transformar `KeyError` em `AttributeError`?

Dentro de __getattr__ temos:

try:
    return self._dados[nome]
except KeyError:
    raise AttributeError(f"'{nome}' não existe na configuração") from None

O dicionário expressa ausência através de:

KeyError

Mas estamos implementando acesso a atributos.

Nesse protocolo, a ausência deve ser comunicada através de:

AttributeError

Isso é importante porque outros mecanismos de Python também dependem dessa exceção para determinar se um atributo existe. from None suprime a exibição automática do encadeamento com o KeyError anterior no traceback, deixando visível apenas a exceção que representa corretamente a abstração pública da classe (PYTHON SOFTWARE FOUNDATION, 2026j). Sem from None, Python mostraria também o contexto da exceção anterior.

A próxima camada: descriptors

Até aqui customizamos operações diretamente sobre a instância.

Descriptors resolvem outro problema: permitir que um atributo armazenado na classe controle o que acontece quando é lido, escrito ou removido.

O protocolo utiliza:

__get__
__set__
__delete__

Conceitualmente:

obj.atributo
    ↓
Python encontra um objeto descriptor na classe
    ↓
__get__(...)

ou, durante escrita:

obj.atributo = valor
        ↓
__set__(...)

Esse mecanismo está por trás de recursos fundamentais da própria linguagem, incluindo property, métodos ligados e classmethod (PYTHON SOFTWARE FOUNDATION, 2026k).

Por exemplo:

class Pessoa:
    def __init__(self, nome: str) -> None:
        self._nome = nome

    @property
    def nome(self) -> str:
        return self._nome

O objeto criado por property participa do protocolo de descriptors.

Não precisamos aprofundar a mecânica inteira agora. O ponto importante é perceber que acesso a atributos também é extensível através de protocolos do modelo de dados.

2.8. Protocolos são mais do que nomes de métodos

Podemos agora refinar a definição.

Um protocolo não significa apenas:

“Existe um método com determinado nome.”

Ele também envolve o contrato semântico esperado daquele método.

Por exemplo:

__len__ deve representar tamanho e retornar um inteiro não negativo;
__getitem__ de uma sequência deve usar exceções apropriadas para índices inválidos;
um iterador deve sinalizar seu fim através de StopIteration;
__eq__ pode devolver NotImplemented para operandos que não sabe comparar;
__hash__ precisa permanecer coerente com igualdade.

É possível escrever um método com o nome correto e ainda implementar o protocolo de maneira ruim.

Por isso, vamos começar aplicando esse princípio a uma única classe, que continuará evoluindo na próxima parte da série.

Nossa base será um vetor N-dimensional:

class Vector:
    def __init__(self, *componentes: float) -> None:
        self._componentes = list(componentes)

Agora podemos criar:

Vector(3, 4)
Vector(1, 2, 3)
Vector(2, 5, 8, 13)

Os componentes ficam armazenados em uma coleção interna:

_componentes

O Vector deste artigo terá duas decisões de projeto importantes:

Os valores dos componentes poderão ser alterados;
A quantidade de componentes permanecerá fixa depois da construção.

Portanto, ele será mutável quanto aos valores, mas não oferecerá operações que adicionem ou removam dimensões.

Para fins didáticos também permitiremos:

Vector()

representando um vetor sem componentes. Um domínio real poderia rejeitar essa construção caso ela não fizesse sentido.

A partir daqui, cada novo método deve respeitar essas mesmas decisões. Nesta parte, começaremos pela representação textual; na próxima, continuaremos evoluindo o mesmo Vector através dos protocolos de tamanho, indexação, iteração e comparação.

3. Representação: `repr` e `str`

Comecemos pelo comportamento mais visível.

Sem __repr__ ou __str__ customizados:

v = Vector(3, 4)

v

no CPython normalmente produz algo parecido com:

<__main__.Vector object at 0x...>

O formato exato dessa representação padrão não deve ser tratado como parte do contrato da nossa classe.

O que queremos responder é:

Como um Vector deve se representar textualmente?

Python oferece dois métodos principais para isso.

Aspecto	`__repr__`	`__str__`
Papel na documentação	representação oficial	representação informal ou facilmente imprimível
Objetivo comum	rica em informação e pouco ambígua	conveniente e legível
Uso típico	REPL, debugging, logs técnicos	apresentação para leitura humana
Acionado por	`repr(v)`, `f"{v!r}"`	`str(v)`, `print(v)`, `f"{v}"`, `f"{v!s}"`

A distinção “desenvolvedor versus usuário final” pode ser uma analogia útil, mas não é a definição normativa.

A documentação define __repr__ como responsável pela representação “oficial” e recomenda, quando possível, uma forma parecida com uma expressão Python capaz de recriar um objeto equivalente. Já __str__ pode produzir uma representação mais conveniente ou concisa (PYTHON SOFTWARE FOUNDATION, 2026c).

Vamos começar por __repr__:

class Vector:
    # ... __init__ da seção anterior

    def __repr__(self) -> str:
        componentes = ", ".join(
            repr(componente)
            for componente in self._componentes
        )

        return f"Vector({componentes})"

Agora:

v = Vector(3, 4)

repr(v)
# 'Vector(3, 4)'

v
# Vector(3, 4)

E para dimensões diferentes:

Vector(1, 2, 3)
# Vector(1, 2, 3)

Vector()
# Vector()

A representação acompanha os dados realmente armazenados. Não existe mais nenhuma hipótese hardcoded de que um vetor precise possuir apenas x e y.

Agora adicionamos uma forma mais compacta para __str__:

class Vector:
    # ...

    def __str__(self) -> str:
        componentes = ", ".join(
            str(componente)
            for componente in self._componentes
        )

        return f"({componentes})"

Com isso:

v = Vector(3, 4)

repr(v)
# 'Vector(3, 4)'

str(v)
# '(3, 4)'

print(v)
# (3, 4)

f"{v}"
# '(3, 4)'

f"{v!s}"
# '(3, 4)'

f"{v!r}"
# 'Vector(3, 4)'

O fallback de `str`

Existe ainda uma relação importante entre os dois métodos.

Se definirmos __repr__, mas não __str__, a representação oficial também é utilizada quando uma representação informal é necessária (PYTHON SOFTWARE FOUNDATION, 2026c).

Por isso, uma classe com apenas:

def __repr__(self) -> str:
    return "..."

já melhora tanto:

repr(obj)

quanto:

str(obj)
print(obj)

O contrário não possui a mesma relação: implementar apenas __str__ não substitui a necessidade de uma representação oficial apropriada.

E os containers?

Observe:

v = Vector(3, 4)

[v]
# [Vector(3, 4)]

Mesmo que:

str(v)

produza:

(3, 4)

a representação de uma list utiliza a representação oficial de seus elementos.

Isso é útil para debugging:

vetores = [
    Vector(1, 2),
    Vector(3, 4),
]

vetores
# [Vector(1, 2), Vector(3, 4)]

O container consegue mostrar claramente quais objetos contém, sem depender da versão mais informal produzida por __str__.

4. Conclusão

Ao longo desta parte, saímos da ideia de que métodos como __len__, __repr__ ou __add__ são apenas nomes especiais que Python chama automaticamente. O ponto central é mais amplo: eles são pontos de integração entre os nossos tipos e os protocolos da linguagem.

Quando escrevemos:

len(obj)

ou:

a * b

ou ainda:

obj.nome

não estamos apenas chamando funções ou operadores isolados. Estamos** acionando comportamentos definidos pelo modelo de dados, cada um com suas próprias regras de resolução e seus próprios contratos**.

Foi por isso que, ao longo do artigo, vimos que:

len(obj) não é equivalente a uma chamada comum de obj.__len__();
__new__ e __init__ participam de momentos diferentes da criação de uma instância;
__del__ não deve ser confundido com gerenciamento determinístico de recursos;
NotImplemented faz parte da negociação entre operandos;
__getattr__ funciona como fallback no acesso a atributos;
descriptors formam outro protocolo por trás de mecanismos como property;
__repr__ e __str__ representam contratos diferentes para a representação textual de um objeto.

Esses exemplos também mostram por que implementar um dunder method não significa apenas usar o nome correto. Para participar bem de um protocolo, a classe precisa respeitar a semântica esperada daquela operação.

O Vector introduzido no final desta parte será nosso ponto de continuidade.

Até aqui, definimos como ele armazena seus componentes e como deve se representar:

Vector(3, 4)

ou, em sua forma informal:

(3, 4)

Na próxima parte, a pergunta muda.

Em vez de observar protocolos de forma mais isolada, vamos acompanhar o que acontece quando vários deles precisam coexistir no mesmo tipo. Vamos decidir, entre outras coisas:

len(v)

deve representar o quê?

Como:

v[0]
v[-1]
v[1:3]

devem se comportar?

O que torna:

for componente in v:
    ...

possível?

E se o Vector for mutável, como isso afeta:

v1 == v2

e sua possibilidade de ser usado em um set ou como chave de dict?

É nesse ponto que os protocolos deixam de parecer recursos independentes e passam a revelar algo ainda mais importante sobre o modelo de dados: decisões de comportamento em uma parte da classe podem impor consequências sobre várias outras.

Na Parte 3, continuaremos justamente daí, evoluindo o mesmo Vector através dos protocolos de tamanho, indexação, iteração, igualdade e hashing.

Referências

PYTHON SOFTWARE FOUNDATION. 3.1. Objects, values and types. In: Python 3.14.7 documentation. [S. l.]: Python Software Foundation, 2026a. Disponível em: https://docs.python.org/3.14/reference/datamodel.html#objects-values-and-types. Acesso em: 14 ago. 2026.

PYTHON SOFTWARE FOUNDATION. 3.3.13. Special method lookup. In: Python 3.14.7 documentation. [S. l.]: Python Software Foundation, 2026b. Disponível em: https://docs.python.org/3.14/reference/datamodel.html#special-method-lookup. Acesso em: 14 ago. 2026.

PYTHON SOFTWARE FOUNDATION. 3.3.1. Basic customization. In: Python 3.14.7 documentation. [S. l.]: Python Software Foundation, 2026c. Disponível em: https://docs.python.org/3.14/reference/datamodel.html#basic-customization. Acesso em: 14 ago. 2026.

PYTHON SOFTWARE FOUNDATION. 3.3.9. With Statement Context Managers. In: Python 3.14.7 documentation. [S. l.]: Python Software Foundation, 2026d. Disponível em: https://docs.python.org/3.14/reference/datamodel.html#with-statement-context-managers. Acesso em: 14 ago. 2026.

PYTHON SOFTWARE FOUNDATION. 3.2.2. NotImplemented. In: Python 3.14.7 documentation. [S. l.]: Python Software Foundation, 2026e. Disponível em: https://docs.python.org/3.14/reference/datamodel.html#notimplemented. Acesso em: 14 ago. 2026.

PYTHON SOFTWARE FOUNDATION. 3.3.8. Emulating numeric types. In: Python 3.14.7 documentation. [S. l.]: Python Software Foundation, 2026f. Disponível em: https://docs.python.org/3.14/reference/datamodel.html#emulating-numeric-types. Acesso em: 14 ago. 2026.

PYTHON SOFTWARE FOUNDATION. NotImplementedError. In: Built-in Exceptions — Python 3.14.7 documentation. [S. l.]: Python Software Foundation, 2026g. Disponível em: https://docs.python.org/3.14/library/exceptions.html#NotImplementedError. Acesso em: 14 ago. 2026.

PYTHON SOFTWARE FOUNDATION. 3.3.2. Customizing attribute access. In: Python 3.14.7 documentation. [S. l.]: Python Software Foundation, 2026h. Disponível em: https://docs.python.org/3.14/reference/datamodel.html#customizing-attribute-access. Acesso em: 14 ago. 2026.

PYTHON SOFTWARE FOUNDATION. 9.6. Private Variables. In: The Python Tutorial — Python 3.14.7 documentation. [S. l.]: Python Software Foundation, 2026i. Disponível em: https://docs.python.org/3.14/tutorial/classes.html#private-variables. Acesso em: 14 ago. 2026.

PYTHON SOFTWARE FOUNDATION. 7.8. The raise statement. In: Python Language Reference — Python 3.14.7 documentation. [S. l.]: Python Software Foundation, 2026j. Disponível em: https://docs.python.org/3.14/reference/simple_stmts.html#the-raise-statement. Acesso em: 14 ago. 2026.

PYTHON SOFTWARE FOUNDATION. Descriptor Guide — Descriptor protocol. In: Python 3.14.7 documentation. [S. l.]: Python Software Foundation, 2026k. Disponível em: https://docs.python.org/3.14/howto/descriptor.html#descriptor-protocol. Acesso em: 14 ago. 2026.

Nota editorial: Este artigo foi desenvolvido e revisado pelo autor com apoio de IA nas etapas de pesquisa, auditoria técnica e revisão editorial. As afirmações técnicas foram verificadas com base nas fontes oficiais indicadas nas referências.

Python Data Model - Part 1

Bruno Teixeira Lopes — Tue, 28 Jul 2026 22:54:43 +0000

Leia a versão em português deste artigo aqui.

1. Introduction

Ever wondered why modifying a list inside a function changes the original list, but modifying a number doesn't? You've just run into one of the most fundamental — and most misunderstood — concepts in Python: its data model.

Understanding how Python represents, identifies, and compares objects isn't just theory: it's what saves you from subtle bugs related to aliasing, incorrect comparisons, and unexpected side effects in mutable containers.

In this first article of the series, we'll build the foundation you need for that: what an object actually is in Python, the difference between identity and equality, what mutability really means, how an object is born and dies, and how all of this connects once objects live inside containers.

This article assumes you're already comfortable with basic Python syntax (variables, lists, dictionaries, functions). If that's you, let's get straight to it.

2. Everything is an object

The data model defines how values are represented and how they behave in Python. Every piece of data your program handles is an object: numbers, strings, lists, functions, classes, and even modules (PYTHON SOFTWARE FOUNDATION, 2026a).

Every Python object has three essential characteristics:

Identity: the object's address in memory. Checked with id(object_name).
Type: defines which values and operations the object supports. Checked with type(object_name).
Value: the content the object represents, which may or may not change depending on the object's mutability.

Type affects nearly every aspect of an object's behavior. That's even true for identity: some types have a single instance shared across the entire program, which is why the correct way to compare them is by identity (is), not equality (==):

None represents the absence of a value;
NotImplemented signals that a special operation doesn't support the operands it received;
..., also called Ellipsis, can be used as a sentinel and in extended slicing operations.

type(None)            # <class 'NoneType'>
type(NotImplemented)  # <class 'NotImplementedType'>
type(...)             # <class 'ellipsis'>

For single-instance types, is is always the recommended way to check for absence of value:

x ==  None # WRONG
x is None # CORRECT

3. Identity vs Equality

As we just saw, an object's identity refers to its memory address: id(x) returns an int representing the memory location where x is stored. Equality, on the other hand, checks whether the values of two objects are the same, using the magic method __eq__ — we'll dig deeper into that method in upcoming chapters.

is: compares identity.
==: compares content or value.

This distinction between identity and equality is the foundation for understanding mutability.

4. Mutable vs Immutable

An object's mutability is determined by its type. A mutable object can have its value changed after creation. An immutable object cannot be modified; any operation on it produces a new object (PYTHON SOFTWARE FOUNDATION, 2026b).

Immutable	Mutable
`NoneType`	`list`
`bool`	`dict`
`int`, `float`, `complex`	`set`
`str`, `tuple`, `range`	`bytearray`
`bytes`, `frozenset`

Mutation changes the object itself; reassignment makes the name point to a new object.

Example with a mutable object:

items = ['a', 'b']  # list is mutable
alias = items
items.append('c')
items  # ['a', 'b', 'c']
alias  # ['a', 'b', 'c']

Example with an immutable object:

total = 10  # int is immutable
alias = total
total += 5  # a new object with value 15 is created; total now points to it
total  # 15
alias  # 10

Immutable objects can hold references to mutable objects, because immutability in Python affects only the object's reference structure, not the content it points to.

record = ("Alyne", ["Python"])
record[1].append("SQL")
record  # ("Alyne", ["Python", "SQL"])

The tuple record still points to the same references — only the inner list was changed.

5. Object life cycle

An object's life cycle in Python has four main phases: creation and memory allocation, attribute initialization, active use throughout the program via references, and destruction with memory release controlled by reference counting and the garbage collector.

import sys

a = [1, 2, 3]
sys.getrefcount(a)  # number of active references to the object (includes getrefcount's own temporary reference)

b = a  # new reference to the same object
sys.getrefcount(a)  # the count goes up, since 'a' and 'b' now point to the same object

When an object becomes unreachable — that is, when its reference count reaches zero — it can be garbage collected by CPython through a reference-counting scheme with delayed detection of cyclically linked garbage. This cyclic collection is optional and doesn't guarantee that all garbage containing circular references will actually be collected.

6. Containers

Container objects are data structures capable of holding other objects — in other words, objects that contain references to others.

They can hold values of different types at the same time, support iteration through loops, and it's common to use the in operator to efficiently check whether an item is present in a container — a check that, internally, relies on equality (==), not identity.

Main container types:

Lists (list): ordered, mutable sequences, defined with square brackets [].
Tuples (tuple): ordered, immutable sequences, defined with parentheses ().
Dictionaries (dict): collections of key-value pairs, defined with curly braces {}.
Sets (set): collections of unique, unordered elements, also defined with curly braces {}.

Watch out for a common gotcha: an empty {} creates a dict, not a set. To create an empty set, you need to use set() explicitly.

Since containers hold references, not copies, everything we've covered about identity, equality, and mutability applies directly here: modifying a mutable object inside a container affects every variable that references that same object — even if the container itself is immutable, as we saw with the tuple example in section 4.

7. Conclusion

Identity, equality, mutability, life cycle, and containers aren't isolated topics — they're facets of the same core concept: in Python, variables are references to objects, not boxes holding values. Understanding that is what lets you predict, with confidence, when a change will propagate and when it will produce a brand-new object.

That foundation is what the next step of the series builds on: magic methods (dunder methods), the protocol Python uses behind seemingly simple operations like len(obj), obj[key], or for item in obj. In Part 2, we'll see how these methods let objects you create behave just like the language's built-in types.

References

PYTHON SOFTWARE FOUNDATION. 3. Data model. In: Python 3.14.6 Documentation. [S. l.]: Python Software Foundation, 2026a. Available at: https://docs.python.org/3/reference/datamodel.html. Accessed on: Jul. 28, 2026.

PYTHON SOFTWARE FOUNDATION. Built-in Types. In: Python 3.14.6 Documentation. [S. l.]: Python Software Foundation, 2026b. Available at: https://docs.python.org/3/library/stdtypes.html. Accessed on: Jul. 28, 2026.

Modelo de Dados Python - Parte 1

Bruno Teixeira Lopes — Tue, 28 Jul 2026 22:51:54 +0000

Read this article in English here.

1. Introdução

Se você já se perguntou por que alterar uma lista dentro de uma função muda a lista original, mas alterar um número não, você esbarrou em um dos conceitos mais fundamentais (e mais mal compreendidos) de Python: o modelo de dados da linguagem.

Entender como Python representa, identifica e compara objetos não é só teoria: é o que evita bugs sutis relacionados a aliasing, comparações incorretas e efeitos colaterais inesperados em containers mutáveis.

Neste primeiro artigo da série, vamos construir a base necessária para isso: o que é um objeto em Python, a diferença entre identidade e igualdade, o que realmente significa mutabilidade, como um objeto nasce e morre, e como tudo isso se conecta quando objetos são armazenados em containers.

Este artigo assume que você já tem familiaridade com a sintaxe básica de Python (variáveis, listas, dicionários, funções). Se esse é o seu caso, vamos direto ao ponto.

2. Tudo é objeto

O modelo de dados define como os valores são representados e como se comportam em Python. Todo dado manipulado pelo programa é um objeto: números, strings, listas, funções, classes e até módulos (PYTHON SOFTWARE FOUNDATION, 2026a).

Um objeto Python conta com três características essenciais:

Identidade: distingue um objeto de todos os outros e permanece a mesma durante toda a sua existência. Pode ser consultada com id(nome_objeto). No CPython, especificamente, id() corresponde ao endereço de memória do objeto.
Tipo: define quais valores e operações o objeto aceita. Consultado com type(nome_objeto).
Valor: conteúdo representado pelo objeto, podendo ou não ser alterado a depender da mutabilidade do objeto.

Os tipos afetam quase todos os aspectos do comportamento do objeto. Isso vale até para a identidade: alguns tipos possuem uma única instância em todo o programa, e por isso a forma correta de compará-los é por identidade (is), não por igualdade (==):

None representa ausência de valor;
NotImplemented informa que uma operação especial não oferece suporte aos operandos recebidos;
..., também chamado de Ellipsis, pode ser usado como uma sentinela e em operações especiais de fatiamento.

type(None)            # <class 'NoneType'>
type(NotImplemented)  # <class 'NotImplementedType'>
type(...)             # <class 'ellipsis'>

Para instâncias únicas, o operador is é sempre a forma recomendada de checar ausência de valor:

x ==  None # ERRADO
x is None # CORRETO

3. Identidade vs Igualdade

Como vimos, a identidade distingue um objeto de todos os demais e permanece estável durante sua existência. id(x) retorna um inteiro que representa essa identidade; no CPython, especificamente, esse valor corresponde ao endereço de memória do objeto. Igualdade, por outro lado, verifica a relação de valor definida entre dois objetos através de == — comportamento que pode ser customizado por eq, um dos métodos especiais que veremos nas próximas partes.

is: compara identidades.
==: compara conteúdo ou valores.

Essa distinção entre identidade e igualdade é a base para entender mutabilidade.

4. Mutável vs Imutável

A mutabilidade de um objeto é determinada pelo seu tipo. Um objeto mutável pode ter seu valor alterado depois de criado. Um objeto imutável não pode ser modificado; uma operação sobre ele produz outro objeto (PYTHON SOFTWARE FOUNDATION, 2026b).

Imutáveis	Mutáveis
`NoneType`	`list`
`bool`	`dict`
`int`, `float`, `complex`	`set`
`str`, `tuple`, `range`	`bytearray`
`bytes`, `frozenset`

A mutação altera o próprio objeto; a reatribuição faz o nome apontar para um novo objeto.

Exemplo com objeto mutável:

items = ['a', 'b']  # list é mutável
alias = items
items.append('c')
items  # ['a', 'b', 'c']
alias  # ['a', 'b', 'c']

Exemplo com objeto imutável:

total = 10  # int é imutável
alias = total
total += 5  # um novo objeto com valor 15 é criado; total passa a apontar para ele
total  # 15
alias  # 10

Objetos imutáveis podem conter referências a objetos mutáveis, pois a imutabilidade em Python afeta apenas a estrutura de referências do objeto, não o conteúdo interno ao qual ele aponta.

record = ("Alyne", ["Python"])
record[1].append("SQL")
record  # ("Alyne", ["Python", "SQL"])

A tupla record continua apontando para as mesmas referências — apenas a lista interna foi alterada.

5. Ciclo de vida dos objetos

O ciclo de vida de um objeto começa com sua criação e continua enquanto ele puder ser alcançado pelo programa através de referências. Quando um objeto deixa de ser alcançável, ele pode se tornar elegível para coleta, mas Python não garante que essa liberação aconteça imediatamente.

No CPython, especificamente, o gerenciamento de memória utiliza principalmente contagem de referências, complementada por um garbage collector capaz de detectar ciclos de referências. Por isso, muitos objetos são liberados assim que deixam de possuir referências, enquanto ciclos podem exigir uma etapa adicional de coleta. Esse é um detalhe da implementação CPython, não uma garantia geral da linguagem.

Podemos observar parte deste comportamento no CPython com:

import sys

a = [1, 2, 3]
sys.getrefcount(a)  # número de referências ativas ao objeto (inclui a referência temporária do próprio getrefcount)

b = a  # nova referência para o mesmo objeto
sys.getrefcount(a)  # o valor aumenta, pois agora 'a' e 'b' apontam para o mesmo objeto

6. Containers

Objetos containers são estruturas de dados capazes de armazenar outros objetos, ou seja, são objetos que contêm referências a outros.

Eles podem guardar dados de tipos diferentes ao mesmo tempo, permitem percorrer seus elementos usando laços de repetição, e é muito comum utilizar o operador in para verificar se um item está presente em um container. A forma exata dessa busca depende do tipo e dos protocolos que ele implementa (comportamento que aprofundaremos nas próximas partes).

Tipos principais de containers:

Listas (list): sequências ordenadas e mutáveis, definidas por colchetes [].
Tuplas (tuple): sequências ordenadas e imutáveis, definidas por parênteses ().
Dicionários (dict): coleções de pares chave-valor, definidos por chaves {}.
Conjuntos (set): coleções de elementos únicos e não ordenados, também definidos por chaves {}.

Atenção a uma pegadinha comum: {} vazio cria um dict, não um set. Para criar um conjunto vazio, é preciso usar set() explicitamente.

Como containers guardam referências e não cópias, tudo o que vimos sobre identidade, igualdade e mutabilidade se aplica de forma direta aqui: alterar um objeto mutável dentro de um container afeta todas as variáveis que referenciam esse mesmo objeto — mesmo que o container em si seja imutável, como vimos no exemplo da tupla na seção 4.

7. Conclusão

Identidade, igualdade, mutabilidade, ciclo de vida e containers são faces do mesmo conceito central: em Python, variáveis são referências a objetos, não caixas que guardam valores. Entender isso é o que permite prever, com segurança, quando uma alteração vai se propagar e quando vai gerar um objeto novo.

Essa base sustenta o próximo passo da série: entender como os métodos especiais permitem que nossos tipos participem dos protocolos da própria linguagem. Na Parte 2, veremos o que existe por trás de operações como len(obj), da criação e finalização de instâncias, da sobrecarga de operadores, do acesso a atributos e das representações produzidas por repr() e str().

Referências

PYTHON SOFTWARE FOUNDATION. 3. Modelo de dados. In: Documentação Python 3.14.6. [S. l.]: Python Software Foundation, 2026a. Disponível em: https://docs.python.org/pt-br/3/reference/datamodel.html. Acesso em: 28 jul. 2026.

PYTHON SOFTWARE FOUNDATION. Tipos embutidos. In: Documentação Python 3.14.6. [S. l.]: Python Software Foundation, 2026b. Disponível em: https://docs.python.org/pt-br/3/library/stdtypes.html. Acesso em: 28 jul. 2026.

DEV Community: Bruno Teixeira Lopes

[Boost]

Python Data Model - Part 2: Protocols and Special Methods

Python Data Model - Part 2: Protocols and Special Methods

1. From Part One to Language Protocols

2. What Are Special Methods

2.1. Operation First, Method Second

2.2. Special Method Lookup Is Different

2.3. A Map of Main Groups

2.4. Creation: __new__ and __init__

2.5. Finalization: __del__ Is Not a Resource Manager

2.6. Arithmetic: NotImplemented and Reflected Operations

And Why Does __rmul__ Exist?

2.7. Attributes: __getattr__ and __setattr__

Why Does _data Start With an Underscore?

And Why Do We Use object.__setattr__?

Recursion Pitfall

Why Transform KeyError Into AttributeError?

The Next Layer: Descriptors

2.8. Protocols Are More Than Method Names

3. Representation: __repr__ and __str__

The Fallback of __str__

And Containers?

4. Conclusion

References

Quem puder dar uma força na parte 2 da série, to aprendendo e curtindo muito produzir estes conteúdos!

Modelo de Dados Python - Parte 2: Protocolos e métodos especiais

Modelo de Dados Python - Parte 2: Protocolos e métodos especiais

1. Da primeira parte aos protocolos da linguagem

2. O que são métodos especiais

2.1. Operação primeiro, método depois

2.2. O lookup de métodos especiais é diferente

2.3. Um mapa dos principais grupos

2.4. Criação: __new__ e __init__

2.5. Finalização: __del__ não é um gerenciador de recursos

2.6. Aritmética: NotImplemented e operações refletidas

E por que existe __rmul__?

2.7. Atributos: __getattr__ e __setattr__

Por que _dados começa com underscore?

E por que usamos object.__setattr__?

Armadilha de recursão

Por que transformar KeyError em AttributeError?

A próxima camada: descriptors

2.8. Protocolos são mais do que nomes de métodos

3. Representação: __repr__ e __str__

O fallback de __str__

E os containers?

4. Conclusão

Referências

Python Data Model - Part 1

1. Introduction

2. Everything is an object

3. Identity vs Equality

4. Mutable vs Immutable

5. Object life cycle

6. Containers

7. Conclusion

References

Modelo de Dados Python - Parte 1

1. Introdução

2. Tudo é objeto

3. Identidade vs Igualdade

4. Mutável vs Imutável

5. Ciclo de vida dos objetos

6. Containers

7. Conclusão

Referências

2.4. Creation: `new` and `init`

2.5. Finalization: `del` Is Not a Resource Manager

2.6. Arithmetic: `NotImplemented` and Reflected Operations

And Why Does `rmul` Exist?

2.7. Attributes: `getattr` and `setattr`

Why Does `_data` Start With an Underscore?

And Why Do We Use `object.setattr`?

Why Transform `KeyError` Into `AttributeError`?

3. Representation: `repr` and `str`

The Fallback of `str`

2.4. Criação: `new` e `init`

2.5. Finalização: `del` não é um gerenciador de recursos

2.6. Aritmética: `NotImplemented` e operações refletidas

E por que existe `rmul`?

2.7. Atributos: `getattr` e `setattr`

Por que `_dados` começa com underscore?

E por que usamos `object.setattr`?

Por que transformar `KeyError` em `AttributeError`?

3. Representação: `repr` e `str`

O fallback de `str`