Mastering Object-oriented Python: If you want to master object-oriented Python programming this book is a must-have. With 750 code samples and a relaxed tutorial, it's a seamless route to programming Python.

Python has two string representations of an object. These are closely aligned with the built-in functions repr(), str(), print(), and the string.format() method.

Let's look at the default implementations first.

The following is a simple class hierarchy...

The __format__() method is used by string.format() as well as the format() built-in function. Both of these interfaces are used to get presentable string versions of a given object.

The following are the two ways in which arguments will be presented to __format__():

Note that something equivalent to "{0!r}".format() or "{0!s}".format() doesn't use the __format__() method. These use __repr__() or __str__() directly.

With a specification of "", a sensible response is return str(self). This provides an obvious consistency between the various string representations...

The built-in hash() function invokes the __hash__() method of a given object. This hash is a calculation which reduces a (potentially complex) value to a small integer value. Ideally, a hash reflects all the bits of the source value. Other hash calculations—often used for cryptographic purposes—can produce very large values.

Python includes two hash libraries. The cryptographic-quality hash functions are in hashlib. The zlib module has two high-speed hash functions: adler32() and crc32(). For relatively simple values, we don't use either of these. For large, complex values, these algorithms can be of help.

The hash() function (and the associated __hash__() method) is used to create a small integer key that is used to work with collections such as set, frozenset, and dict. These collections use the hash value of an immutable object to rapidly locate the object in the collection.

Immutability is important here; we'll mention it many times. Immutable objects don't change...

Python has a pleasant definition of falsity. The reference manual lists a large number of values that will test as equivalent to False. This includes things such as False, 0, '', (), [], and {}. Most other objects will test as equivalent to True.

Often, we'll want to check for an object being "not empty" with a simple statement as follows:

if some_object:
    process( some_object )

Under the hood, this is the job of the bool() built-in function. This function depends on the __bool__() method of a given object.

The default __bool__() method returns True. We can see this with the following code:

>>> x = object()
>>> bool(x)
True

For most classes, this is perfectly valid. Most objects are not expected to be False. For collections, however, this is not appropriate. An empty collection should be equivalent to False. A nonempty collection can return True. We might want to add a method like this to our Deck objects.

If we're wrapping a list, we might have something...

There are relatively few occasions to transform an object into bytes. We'll look at this in detail in Part 2, Persistence and Serialization.

In the most common situation, an application can create a string representation, and the built-in encoding capabilities of the Python IO classes will be used to transform the string into bytes. This works perfectly for almost all situations. The main exception would be when we're defining a new kind of string. In that case, we'd need to define the encoding of that string.

The bytes() function does a variety of things, depending on the arguments:

Python has six comparison operators. These operators have special method implementations. According to the documentation, the mapping works as follows:

We'll return to comparison operators again when looking at numbers in Chapter 7, Creating Numbers.

There's an additional rule regarding what operators are actually implemented that's relevant here. These rules are based on the idea that the object's class on the left defines the required special method. If it doesn't, Python can try an alternative operation by changing the order.

The __del__() method has a rather obscure use case.

The intent is to give an object a chance to do any cleanup or finalization just before the object is removed from memory. This use case is handled much more cleanly by context manager objects and the with statement. This is the subject of Chapter 5, Using Callables and Contexts. Creating a context is much more predictable than dealing with __del__() and the Python garbage collection algorithm.

In the case where a Python object has a related OS resource, the __del__() method is a last chance to cleanly disentangle the resource from the Python application. As examples, a Python object that conceals an open file, a mounted device, or perhaps a child subprocess might all benefit from having the resource released as part of __del__() processing.

The __del__() method is not invoked at any easy-to-predict time. It's not always invoked when the object is deleted by a del statement, nor is it always invoked when an object is deleted...

One use case for the __new__() method is to initialize objects that are otherwise immutable. The __new__() method is where our code can build an uninitialized object. This allows processing before the __init__() method is called to set the attribute values of the object.

The __new__() method is used to extend the immutable classes where the __init__() method can't easily be overridden.

The following is a class that does not work. We'll define a version of float that carries around information on units:

class Float_Fail( float ):
    def __init__( self, value, unit ):
        super().__init__( value )
        self.unit = unit

We're trying (improperly) to initialize an immutable object.

The following is what happens when we try to use this class definition:

>>> s2 = Float_Fail( 6.5, "knots" )
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: float() takes at most 1 argument (2 given)

From this, we see...

The other use case for the __new__() method as a part of a metaclass is to control how a class definition is built. This is distinct from how __new__() controls building an immutable object, shown previously.

A metaclass builds a class. Once a class object has been built, the class object is used to build instances. The metaclass of all class definitions is type. The type() function is used to create class objects.

Additionally, the type() function can be used as a function to reveal the class of an object.

The following is a silly example of building a new, nearly useless class directly with type() as a constructor:

Useless= type("Useless",(),{})

Once we've created this class, we can create objects of this Useless class. However, they won't do much because they have no methods or attributes.

We can use this newly-minted Useless class to create objects, for what little it's worth. The following is an example:

>>> Useless()
<__main__.Useless object...

We've looked at a number of basic special methods, which are essential features of any class that we design. These methods are already part of every class, but the defaults we inherit from the object may not match our processing requirements.

We'll almost always have a need to override __repr__(), __str__(), and __format__(). The default implementations of these methods aren't very helpful at all.

We rarely need to override __bool__() unless we're writing our own collection. That's the subject of Chapter 6, Creating Containers and Collections.

We often need to override the comparison and __hash__() methods. The definitions are suitable for simple immutable objects but not at all appropriate for mutable objects. We may not need to write all the comparison operators; we'll look at the @functools.total_ordering decorator in Chapter 8, Decorators and Mixins – Cross-cutting Aspects.

The other two basic special method names, __new__() and __del__(), are for more specialized purposes. Using...