OOP | Haobin Tan

Object Oriented Programming in Python and

Wed, 04 May 2022 00:00:00 +0000

OOP Basics

Wed, 04 May 2022 00:00:00 +0000

The concept of OOP in Python focuses on creating reusable code. This concept is also known as DRY (Don’t Repeat Yourself).

Class

A class is a blueprint for the object.

Example

class Parrot:

 # class attribute (same for all instances of a class)
 species = "bird"

 # instance attribute (different for every instance of a class)
 def __init__(self, name, age):
 self.name = name
 self.age = age

Object

An object (instance) is an instantiation of a class.

Example:

blu = Parrot("Blu", 10)
woo = Parrot("Woo", 15)

Access class attributes:

>>> blu.species
'bird'
>>> woo.species
'bird'

Access instance attributes:

>>> print(f"{blu.name} is {blu.age} years old.")
Blu is 10 years old.
>>> print(f"{woo.name} is {woo.age} years old.")
Woo is 15 years old.

Methods

Functions defined inside the body of a class
Define the behaviors of an object

Example

class Parrot:

 # class attribute
 species = "bird"

 # instance attribute
 def __init__(self, name, age):
 self.name = name
 self.age = age

 def sing(self, song):
 print(f"{self.name} is singing {song}.")

 def dance(self):
 print(f"{self.name} is dancing.")

>>> blu = Parrot("Blu", 10)
>>> blu.sing("'Happy'")
Blu is singing 'Happy'.

Inheritance

Inheritance enables us to define a class that takes all the functionality from a parent class and allows us to add more.

class SuperClass:

 def __init__(self):
 pass

 def super_method(self):
 pass


class SubClass(SuperClass):

 def __init__(self):
 super().__init__()
 pass

 def super_method(self):
 """Override method of SuperClass"""
 pass

 def sub_method(self):
 """Method that only belongs to SubClass"""
 pass

Example

# parent class
class Bird:

 def __init__(self):
 print("Bird is ready")

 def who_is_this(self):
 print("Bird")

 def swim(self):
 print("Swim faster")

# child class
class Penguin(Bird):

 def __init__(self):
 # call super() function
 # run the __init__() method of the parent class inside the child class.
 super().__init__()
 print("Penguin is ready")

 # overrides method
 def who_is_this(self):
 print("Penguin")

 def run(self):
 print("Run faster")

>>> peggy = Penguin()
Bird is ready
Penguin is ready
>>> peggy.who_is_this()
Penguin
>>> peggy.run()
Run faster

Encapsulation

Encapsulation: Restrict access to methods and variables to prevent data from direct modification.

In python, private attributes is denoted using underscore(s) as the prefix, i.e., _ or __. The main difference between them is:

Prefix _ is just a naming convention indicating a name is meant for internal use. It is NOT enforced by the Python interpreter (except in wildcard imports) and meant as a hint to the programmer only.
Prefix __ triggers name mangling when used in a class context (i.e., can be not directly accessed) and is enforced by the Python interpreter.

More about underscores see: Underscores in Python.

Example:

class Computer:

 def __init__(self):
 self._min_price = 800
 self.__max_price = 900

 def sell(self):
 print(f"Price: {self._min_price} ~ {self.__max_price}")

 def set_max_price(self, max_price):
 self.__max_price = max_price

>>> computer.sell()
Price: 800 ~ 900

Variable with __ prefix can not be directly accessed or modified:

>>> computer.__max_price
---------------------------------------------------------------------------
AttributeError Traceback (most recent call last)
<ipython-input-20-2eb906d81ddf> in <module>()
----> 1 computer.__max_price

AttributeError: 'Computer' object has no attribute '__max_price'

>>> computer.__max_price = 1000
>>> computer.sell()
Price: 800 ~ 900

We have to use setters and getters:

>>> computer.get_max_price()
900

>>> computer.set_max_price(1000)
computer.sell()

In contrast, variable with _ can be directly accessed or modified:

>>> computer._min_price
800
>>> computer._min_price = 950
>>> computer._min_price
950

Polymorphism

Polymorphism is an ability (in OOP) to use a common interface for multiple forms (data types).

Example:

class Parrot:

 def fly(self):
 print("Parrot can fly")

 def swim(self):
 print("Parrot can't swim")

class Penguin:

 def fly(self):
 print("Penguin can't fly")

 def swim(self):
 print("Penguin can swim")

# common interface
def flying_test(bird):
 bird.fly()

#instantiate objects
blu = Parrot()
peggy = Penguin()

# passing the object
flying_test(blu)
flying_test(peggy)

Output

Parrot can fly
Penguin can't fly

Reference

Operator Overloading

Wed, 04 May 2022 00:00:00 +0000

In Python, methods with __ (double underscore) prefix and suffix (e.g., __init__()) are special methods.They are called magic methods or dunder methods (dunder for “double underscore”). They can help override functionality for built-in functions for custom classes.

Essentially, each built-in function or operator has a special method corresponding to it. For example, there’s __len__(), corresponding to len(), and __add__(), corresponding to the + operator.

By default, most of the built-ins and operators will not work with objects of your classes. You must add the corresponding special methods in your class definition to make your object compatible with built-ins and operators. When you do this, the behavior of the function or operator associated with it changes according to that defined in the method.

The Internals of Operations

Every class in Python defines its own behavior for built-in functions and methods. Under the hood, when you pass an instance of some class to a built-in function or use an operator on the instance, it is actually equivalent to calling a special method with relevant arguments.

If there is a built-in function, func(), and the corresponding special method for the function is __func__(), Python interprets a call to the function as obj.__func__(), where obj is the object.
In the case of operators, if you have an operator opr and the corresponding special method for it is __opr__(), Python interprets something like obj1 <opr> obj2 as obj1.__opr__(obj2).

For example

When you’re calling len() on an object, Python handles the call as obj.__len__().
```
>>> a = 'Real Python'
>>> len(a)
11
>>> a.__len__()
11
```
When you use the [] operator on an iterable to obtain the value at an index, Python handles it as itr.__getitem__(index), where itr is the iterable object and index is the index you want to obtain.
```
b = ['Real', 'Python']
>>> b[0]
'Real'
>>> b.__getitem__(0)
'Real'
```

You can see these special methods using the built-in dir() function.

Overloading Built-in Functions

To overload the built-in functions, you only need to define the corresponding special method in your class.

In the following, we’ll demonstrate the overloading with some common built-in functions.

`len()`: Gives a Length to Your Objects

To change the behavior of len(), you need to define the __len__() special method in your class. Whenever you pass an object of your class to len(), your custom definition of __len__() will be used to obtain the result.

Example

class Order:

 def __init__(self, cart, customer):
 self.cart = list(cart)
 self.customer = customer

 def __len__(self):
 return len(self.cart)

>>> order = Order(["apple", "banana"], "Ben")
>>> len(order)
2

Use len() to directly obtain the length of the cart is more pythonic and more intuitive than calling something like order.get_cart_len().

`str()`: Prints Your Objects Prettily

The str() built-in is used to obtain a user-friendly string representation of the object which can be read by a normal user rather than the programmer.
__str__() is the method that is used by Python when you call print() on your object.
__str__() must return a str object

Example

class Order:

 def __init__(self, cart, customer):
 self.cart = list(cart)
 self.customer = customer

 def __len__(self):
 return len(self.cart)

 def __str__(self):
 return f"{self.customer} has {self.__len__()} products in the cart."

>>> order = Order(["apple", "banana"], "Ben")
>>> print(order)
Ben has 2 products in the cart.

`repr()`: Represents Your Objects

The repr() built-in is used to obtain the parsable string representation of an object.
- An object is parsable means that Python should be able to recreate the object from the representation when repr is used in conjunction with functions like eval().
repr() is also the method Python uses to display the object in a REPL session.

Example

class Vector:

 def __init__(self, x_comp, y_comp):
 self.x_comp = x_comp
 self.y_comp = y_comp

 def __repr__(self):
 return f"Vector({self.x_comp}, {self.y_comp})"

>>> vector = Vector(3, 4)
>>> repr(vector)
'Vector(3, 4)'

>>> new_vector = eval(repr(vector))
>>> new_vector # Looking at object; __repr__ used
Vector(3, 4)

Note:

In cases where the __str__() method is not defined, Python uses the __repr__() method to print the object, as well as to represent the object when str() is called on it.

# In the vector example above, we do not defined __str__() method
>>> print(new_vector)
Vector(3, 4) # vector object is printed using __repr__()

If both the methods are missing, it defaults to <__main__.Vector ...>.
__repr__() is the only method that is used to display the object in an interactive session. Absence of it in the class yields <__main__.Vector ...>.
Many of the popular libraries ignore this distinction and use the two methods interchangeably 🤪.

For more about __repr__() and __str__(), check: Python String Conversion 101: Why Every Class Needs a “repr”.

`bool()`: Makes Your Objects Truthy or Falsey

The bool() built-in can be used to obtain the truth value of an object.
The behavior defined here will determine the truth value of an instance in all contexts that require obtaining a truth value such as in if statements.

Example

class Order:

 def __init__(self, cart, customer):
 self.cart = list(cart)
 self.customer = customer

 def __len__(self):
 return len(self.cart)

 def __str__(self):
 return f"{self.customer} has {self.__len__()} products in the cart."

 def __bool__(self):
 return len(self.cart) > 0

>>> order = Order(["apple", "banana"], "Ben")
>>> bool(order)
True
>>> order_2 = Order([], "Amy")
>>> bool(order)
False

Overloading Built-in Operators

Changing the behavior of operators is just as simple as changing the behavior of functions: You define their corresponding special methods in your class, and the operators work according to the behavior defined in these methods.

Usually, these special methods need to accept another argument in the definition other than self, generally referred to by the name other.

`+`: Makes Your Objects Capable of Being Added

The special method corresponding to the + operator is the __add__() method.
It is recommended that __add__() returns a new instance of the class instead of modifying the calling instance itself.

Actually this behaviour is quiet often in Python:

>>> a = "Hello"
>>> b = "World"
>>> a + b
`Hello World`
>>> a # remains unchanged
'Hello '

>>> list_1 = [1, 2]
>>> list_2 = [3, 4]
>>> list_1 + list_2
[1, 2, 3, 4]
>>> list_1 # remains unchanged
[1, 2]

Example (using the Order class above):

class Order:

 def __init__(self, cart, customer):
 self.cart = list(cart)
 self.customer = customer

 def __len__(self):
 return len(self.cart)

 def __str__(self):
 return f"{self.customer} has {self.__len__()} products in the cart."

 def __bool__(self):
 return len(self.cart) > 0

 def __add__(self, other):
 new_cart = self.cart.copy()
 new_cart + other if isinstance(other, list) else new_cart.append(other)
 return Order(new_cart, self.customer)

>>> order = Order(["apple", "banana"], "Ben")
>>> (order + "pear").cart # New Order instance
['apple', 'banana', 'pear']
>>> order.cart # Original instance unchanged
['apple', 'banana']

>>> order = order + 'mango' # Changing the original instance
>>> order.cart
['apple', 'banana', 'mango']

Similarly, you have the __sub__(), __mul__(), and other special methods which define the behavior of -, *, and so on. These methods should return a new instance of the class as well.

Shortcuts: the `+=` operator

The += operator stands as a shortcut to the expression obj1 = obj1 + obj2
Corresponding special method: __iadd()__
The __iadd__() method should make changes directly to the self argument and return the result, which may or may not be self.

Roughly, any += use on two objects is equivalent to:
```
result = obj1 + obj2
obj1 = resul
```

Example:

class Order:

 def __init__(self, cart, customer):
 self.cart = list(cart)
 self.customer = customer

 def __len__(self):
 return len(self.cart)

 def __str__(self):
 return f"{self.customer} has {self.__len__()} products in the cart."

 def __bool__(self):
 return len(self.cart) > 0

 def __add__(self, other):
 new_cart = self.cart.copy()
 new_cart + other if isinstance(other, list) else new_cart.append(other)
 return Order(new_cart, self.customer)

 def __iadd__(self, other):
 self.cart + other if isinstance(other, list) else self.cart.append(other)
 return self

>>> order = Order(["apple", "banana"], "Ben")
>>> order += "mange"
>>> order.cart
['apple', 'banana', 'mange']

Always make sure that you’re returning something in your implementation of __iadd__() and that it is the result of the operation and not anything else.

Similar to __iadd__(), you have __isub__(), __imul__(), __idiv__() and other special methods which define the behavior of -=, *=, /=, and others alike.

`[]`: Indexes and Slices Your Objects

The [] operator is called the indexing operator and is used in various contexts in Python such as g

etting the value at an index in sequences,
getting the value associated with a key in dictionaries,
obtaining a part of a sequence through slicing.

You can change its behavior using the __getitem__() special method.

Example:

class Order:

 def __init__(self, cart, customer):
 self.cart = list(cart)
 self.customer = customer

 def __len__(self):
 return len(self.cart)

 def __str__(self):
 return f"{self.customer} has {self.__len__()} products in the cart."

 def __bool__(self):
 return len(self.cart) > 0

 def __add__(self, other):
 new_cart = self.cart.copy()
 new_cart + other if isinstance(other, list) else new_cart.append(other)
 return Order(new_cart, self.customer)

 def __iadd__(self, other):
 self.cart + other if isinstance(other, list) else self.cart.append(other)
 return self

 def __getitem__(self, key):
 return self.cart[key]

>>> order = Order(["apple", "banana"], "Ben")
>>> order[1]
'banana'

Reverse Operators: Makes Your Classes Mathematically Correct

While defining the __add__(), __sub__(), __mul__(), and similar special methods allows you to use the operators when your class instance is the left-hand side operand, the operator will NOT work if the class instance is the right-hand side operand.

If your class represents a mathematical entity like a vector, a coordinate, or a complex number, applying the operators should work in both the cases since it is a valid mathematical operation. To help you make your classes mathematically correct, Python provides you with reverse special methods such as __radd__(), __rsub__(), __rmul__(), and so on.

These handle calls such as x + obj, x - obj, and x * obj, where x is not an instance of the concerned class.
These reverse special methods should return a new instance of class with the changes of the operation rather than modifying the calling instance itself.

Resource

Section 3.3, Special Method Names of the Data Model section in the Python documentation
Fluent Python by Luciano Ramalho
Python Tricks: The Book

Reference

Operator and Function Overloading in Custom Python Classes

Object Comparison: == vs is

Sun, 04 Dec 2022 00:00:00 +0000

The == operator compares by checking for equality (the objects referred to by the variables are equal, i.e. have the same contents)
The is operator comparies identities (whether two variables are in fact pointing to the same identical object)

Example

>>> a = [1, 2, 3]
>>> b = a

>>> a
[1, 2, 3]
>>> b
[1, 2, 3]

>>> a == b
True

>>> a is b
True

a and b point to the same list object, as we assigned them earlier.

>>> c = list(a) # create an identical copy of the list a

>>> c
[1, 2, 3]

>>> a == c # should be true, as a and c have the same content
True

>>> a is c
False

String Conversion

Sun, 04 Dec 2022 00:00:00 +0000

TL;DR

Control to-string conversion in your own classes using the __str__ and __repr__ “dunder” methods
The result of __str__ should be readable. The result of __repr__ should be unambiguous.
Always add a __repr__ to your classes. The default implemen- tation for __str__ just calls __repr__.

When you define a custom class in Python and then try to print one of its instances to the console (or inspect it in an interpreter session), by default you will get a string containing the class name and the id of the object instance (which is the object’s memory address in CPython.) → This default “to string” conversion behavior is basic and lacks detail.

Example

class Car:
 def __init__(self, color, mileage):
 self.color = color
 self.mileage = mileage

>>> my_car = Car('red', 37281)
>>> print(my_car)
<__console__.Car object at 0x109b73da0>
>>> my_car
<__console__.Car object at 0x109b73da0>

nstead of building your own to-string conversion machinery, you’ll be better off adding the __str__ and __repr__ “dunder” methods to your class. They are the Pythonic way to control how objects are converted to strings in different situations

class Car:
 def __init__(self, color, mileage):
 self.color = color
 self.mileage = mileage

 def __str__(self):
 # return f"a {self.color} car"
 return f'a {self.color} car'

>>> my_car = Car('red', 37281)
>>> print(my_car)
'a red car'
>>> my_car
<__console__.Car object at 0x109ca24e0>

`str` vs. `repr`

When print() an object, or involving string, the __str__ method will be called.
inspecting an object in a Python inter- preter session simply prints the result of the object’s __repr__.

Example:

class Car:
 def __init__(self, color, mileage):
 self.color = color
 self.mileage = mileage

 def __str__(self):
 # return f"a {self.color} car"
 return "__str__ for Car"

 def __repr__(self):
 return "__repr__ for Car"

>>> my_car = Car('red', 37281)

>>> print(my_car)
__str__ for Car

>>> '{}'.format(my_car)
'__str__ for Car'

>>> my_car
__repr__ for Car

Interestingly, containers like lists and dicts always use the result of __repr__ to represent the objects they contain. Even if you call str on the container itself:

>>> str([my_car])
'[__repr__ for Car]'

To express your code’s intent more clearly, it’s best to use the built-in str() and repr() functions. Using them is preferable over calling the object’s __str__ or __repr__ directly, as it looks nicer and gives the same result:

>>> str(my_car)
'__str__ for Car'

>>> repr(my_car)
'__repr__ for Car'

Difference of usage of __str__ and __repr__:

The result of the date object’s __str__ function should primarily be readable.
- It’s meant to return a concise textual representation for human consumption—something you’d feel comfortable displaying to a user.
With __repr__, the idea is that its result should be, above all, unambiguous.
- The resulting string is intended more as a debugging aid for developers.
  
  → It needs to be as explicit as possible about what this object is.
- Rule of thumb: make __repr__ strings unambiguous and helpful for developers 💪

Example:

>>> import datetime
>>> today = datetime.date.today()

>>> str(today)
'2022-12-04'

>>> repr(today)
'datetime.date(2022, 12, 4)'

Why Every Class Needs a `repr`

If you don’t add a __str__ method, Python falls back on the result of __repr__ when looking for __str__. Therefore, it is recommended to always add at least a __repr__ method to your classes. This will guarantee a useful string conversion result in almost all cases, with a minimum of implementation work 👏.

Example:

class Car:
 def __init__(self, color, mileage):
 self.color = color
 self.mileage = mileage

 def __str__(self):
 return f"a {self.color} car"

 def __repr__(self):
 return f"{self.__class__.__name__}({self.color!r}, {self.mileage!r})"

Note: using the !r conversion flag makes sure the output string uses repr(self.color) and repr(self.mileage) instead of str(self.color) and str(self.mileage)

Define Your Own Exception Classes

Sun, 04 Dec 2022 00:00:00 +0000

TL;DR

Defining your own exception types will state your code’s intent more clearly and make it easier to debug.
Derive your custom exceptions from Python’s built-in Exception class or from more specific exception classes like ValueError or KeyError.
You can use inheritance to define logically grouped exception hierarchies.

Defining your own error types can be of great value:

You’ll make potential error cases stand out clearly → your functions and modules will become more maintainable.
You can also use custom error types to provide additional debugging information.

→ All of this will improve your Python code and make it easier to under- stand, easier to debug, and more maintainable.

Example: Let’s say you wanted to validate an input string representing a person’s name in your application.

def validate(name):
 if len(name) < 10:
 raise ValueError

However, there’s a downside to using a “high-level” generic exception class like ValueError. When a name fails to validate, it’ll look like this in the debug stack trace:

>>> validate('joe')
Traceback (most recent call last):
 File "<input>", line 1, in <module>
 validate('joe')
 File "<input>", line 3, in validate
 raise ValueError
ValueError

This stack trace isn’t really all that helpful. To be able to fix the problem, your teammate almost certainly has to look up the implementation of validate(). This could be time consuming.

An improvement for this is to introduce a custom exception type to represent a failed name validation:

class NameToShortError(ValueError):
 pass

def validate(name):
 if len(name) < 10:
 raise NameToShortError

The custom NameTooShortError exception is “self-documenting”, which results in a much nicer stack track when the validation fails:

>>> validate('jane')
Traceback (most recent call last):
 File "<input>", line 1, in <module>
 validate('jane')
 File "<input>", line 3, in validate
 raise NameTooShortError(name)
NameTooShortError: jane

Custom exception classes make it much easier to understand what’s going on when things go wrong (and eventually they always do). By spending just 30 seconds on defining a simple exception class, this code snippet became much more communicative already.

Good Practice

It’s good practice to create a custom exception base class for the module and then derive all of your other exceptions from it.

Declare a base class that all of our concrete errors will inherit from. E.g.
```
class BaseValidationError(ValueError):
 pass
```

All of our “real” error classes can be derived from the base error class. This gives a nice and clean exception hierarchy with little extra effort.

E.g.

class NameTooShortError(BaseValidationError):
 pass

class NameTooLongError(BaseValidationError):
 pass

class NameTooCuteError(BaseValidationError):
 pass

Of course you can take this idea further and logically group your exceptions into fine grained sub-hierarchies. But be careful—it’s easy to introduce unnecessary complexity by going overboard with this.

In conclusion, defining custom exception classes makes it easier for your users to adopt an it’s easier to ask for forgiveness than permission (EAFP) coding style that’s considered more Pythonic.

Object Cloning

Sun, 11 Dec 2022 00:00:00 +0000

TL;DR

Making a shallow copy of an object won’t clone child objects. → The copy is not fully independent of the original.
A deep copy of an object will recursively clone child objects.The clone is fully independent of the original, but creating a deep copy is slower.
You can deep or shallow copy arbitrary objects with the standard copy module.

Shallow vs. Deep Copy

For compound objects, there’s an important difference between shallow and deep copying:

Shallow copy
- Constructing a new collection object and then populating it with references to the child objects found in the original → only one level deep
- The copying process does NOT recurse and therefore won’t create copies of the child objects themselves.
Deep copy
- Makes the copying process recursive
  - first constructing a new collection object
  - then recursively populating it with copies of the child objects found in the original
  → Copying an object this way walks the whole object tree to create a fully independent clone of the original object and all of its children.

Shallow Copy

Python’s built-in mutable collections like lists, dicts, and sets can be shallowly copied by calling their factory functions on an existing collection:

new_list = list(original_list)
new_dict = dict(original_dict)
new_set = set(original_set)

Example

we’ll create a new nested list and then shallowly copy it with the list() factory function:

>>> xs = [[1, 2, 3], [4, 5, 6], [7, 8, 9]]
>>> ys = list(xs) # Make a shallow copy

Now ys will be a new and independent object with the same contents as xs:

>>> xs
[[1, 2, 3], [4, 5, 6], [7, 8, 9]]

>>> ys
[[1, 2, 3], [4, 5, 6], [7, 8, 9]]

To further verify that ys is really independent from the original, we add a new sublist ot the original xs and check to make sure this modification didn’t affect the copy ys:

>>> xs.append(['new'])
>>> xs
[[1, 2, 3], [4, 5, 6], [7, 8, 9], ['new']]

>>> ys
[[1, 2, 3], [4, 5, 6], [7, 8, 9]]

However, because we only created a shallow copy of the original list xs, ys still contains references to the original child objects stored in xs. These children were NOT copied. They were merely referenced again in the copied list.

>>> xs[1][0] = 'X'
>>> xs
[[1, 2, 3], ['X', 5, 6], [7, 8, 9], ['new']]

>>> ys
[[1, 2, 3], ['X', 5, 6], [7, 8, 9]]

The diagram below shows how this works:

Use The`copy` Module

The copy module in the Python standard library provides a simple interface for creating shallow and deep copies of arbitrary Python objects.

copy.deepcopy() creates deep copy
copy.copy() creates shallow copy

For built-in collections it’s considered more Pythonic to simply use the list, dict, and set factory functions to create shallow copies.

Abstract Base Class (ABC)

Sun, 11 Dec 2022 00:00:00 +0000

TL;DR

Abstract Base Classes (ABCs) ensure that derived classes implement particular methods from the base class at instantiation time
Using Python’sabc module help avoid bugs and make class hierarchies easier to maintain.

In OOP, inheritance is very common. To make the code of inheritance relationship as maintainable and programmer-friendly as possible, we want to make sure that

instantiating the base class is impossible
forgetting to implement interface methods in one of the sub-classes raises an error as early as possible.

To enforce that a derived class implements a number of meth- ods from the base class, something like this Python idiom is typically used:

class Base:
 def foo(self):
 raise NotImplementedError()

 def bar(self):
 raise NotImplementedError()


class Concrete(Base):
 def foo(self):
 return "foo() called"

 # We forgot to override bar()...

Calling methods on an instance of Base correctly raises NotImplementedError exceptions:

>>> b = Base()
>>> b.foo()
NotImplementedError

Furthermore, instantiating and using Concrete works as expected. If we call an unimplemented method like bar() on it, this also raises an exception:

>>> c = Concrete()

>>> c.foo()
'foo() called'

>>> c.bar()
NotImplementedError

This implementation is decent. However, it has two downsides

instantiate Base just fine without getting an error (which is not expected, as the base class should be uninstantiatable)
provide incomplete subclasses—instantiating Concrete will not raise an error until we call the missing method bar()

We can solve these issues with Python’s abc module. Here’s an updated implemen- tation using an Abstract Base Class defined with the abc module:

from abc import ABCMeta, abstractmethod

class Base(metaclass=ABCMeta):
 @abstractmethod
 def foo(self):
 pass

 @abstractmethod
 def bar(self):
 pass

class Concrete(Base):
 def foo(self):
 pass

 # We forget to declare bar()

This still behaves as expected and creates the correct class hierarchy:

>>> issubclass(Concrete, Base)
True

Benefit of applying the abc module:

Instantiating base class will raise an exception

>>> b = Base()
---------------------------------------------------------------------------
TypeError Traceback (most recent call last)
Cell In [19], line 1
----> 1 b = Base()

TypeError: Can't instantiate abstract class Base with abstract methods bar, foo

Subclasses of Base raise a TypeError at instantiation time whenever we forget to im- plement any abstract methods. The raised exception also tells us which method or methods we’re missing, makes it more difficult to write invalid subclasses.

>>> c = Concrete()
---------------------------------------------------------------------------
TypeError Traceback (most recent call last)
Cell In [10], line 1
----> 1 c = Concrete()

TypeError: Can't instantiate abstract class Concrete with abstract method bar

These advantages often make the class hierarchies more robust and more readily maintainable. Using ABCs states the programmer’s intent clearly and thus makes the code more communicative. 👍

Class vs Instance Variable

Fri, 16 Dec 2022 00:00:00 +0000

TL;DR

Class variables are for data shared by all instances of a class. They belong to a class, not a specific instance and are shared among all instances of a class.
Instance variables are for data that is unique to each instance. They belong to individual object instances and are not shared among the other instances of a class. Each instance variable gets a unique backing store specific to the instance.
Class variables can be incautiously “shadowed” by instance variables of the same name, which could introduceds bugs and odd behaviour.
Be careful and double-check your scoping when dealing with shared state on a class. Automated tests and peer reviews help greatly with that.

Class Variable vs. Instance Variable

Two kinds of data attributes on Python objects

Class variables
- Declared inside the class definition (but outside of any instance methods)
- Not tied to any particular instance of a class
- Class variables store their contents on the class itself, and all objects created from a particular class share access to the same set of class variables.
  - I.e.modifying a class variable affects all object instances at the same time.
Instance variables
- Always tied to a particular object instance
- Contents of an instance vari- able are completely independent from one object instance to the next.
  - I.e. modifying an instance variable only affects one object instance at a time.

Example

class Dog:
 num_legs = 4 # class variabel

 def __init__(self, name):
 self.name = name # instance variable

>>> jack = Dog('Jack')
>>> jill = Dog('Jill')
>>> jack.name, jill.name
('Jack', 'Jill')

We can access the num_legs class variable either directly on each Dog instance or on the class itself :

>>> jack.num_legs, jill.num_legs
(4, 4)

>>> Dog.num_legs
4

If we try to access an instance variable through the class, it’ll fail with an AttributeError.

>>> Dog.name
AttributeError:
"type object 'Dog' has no attribute 'name'"

The reason is that instance variables are specific to each object instance and are created when the __init__ constructor runs—they do NOT even exist on the class itself.

Now let’s say we want jack to have 6 legs. If we directly modify the num_legs class variable on the Dogclass:

>>> Dog.num_legs = 6

>>> jack.num_legs, jill.num_legs
(6, 6)

As we can see, modifying a class variable on the class namespace affects all instances of the class.

Let’s roll back the change to the class variable and instead try to give an extra pair o’ legs specifically to jackonly:

>>> Dog.num_legs = 4
>>> jack.num_legs = 6

>>> jack.num_legs, jill.num_legs, Dog.num_legs
(6, 4, 4)

It seems ok, and we got the result we wanted. But a pitfalls occurs: we introduced a num_legs instance variable to the jack instance. And now the new num_legs instance variable “shadows” the class variable of the same name, overriding and hiding it when we access the object instance scope.

>>> jack.num_legs, jack.__class__.num_legs
(6, 4)

Instance, Class, and Static Methods

Fri, 16 Dec 2022 00:00:00 +0000

TL:DR

Instance methods need a class instance and can access the instance through self.
Class methods don’t need a class instance. They can’t accessthe instance (self) but they have access to the class itself via cls.
Static methods don’t have access to cls or self. They work like regular functions but belong to the class’ namespace.
Static and class methods communicate and (to a certain degree) enforce developer intent about class design. This can have definite maintenance benefits.

Instance vs. Class vs. Static Methods

class MyClass:

 # instance method
 def method(self):
 return "Instance method called", self

 # class method
 @classmethod
 def classmethod(cls):
 return "Class method called", cls

 # static method
 @staticmethod
 def staticmethod():
 return "Static method called"

Instance method (method(self))
- Takes one parameter, self, which points to an instance of MyClass when the method is called
  - Through the self parameter, instance methods can freely access attributes and other methods on the same object.
- instance methods can also access the class itself through the self.__class__ attribute. I.e., instance methods can also modify class state.
Class method (classmethod(cls))
- Marked with a @classmethod decorator
- Takes a cls that points to the class when the method is called
- Since the class method only has access to this cls argument, it can’t modify object instance state. But it can still modify class state that applies across all instances of the class.
Static method (staticmethod)
- Does not take a self or cls parameter
- Can NOT modify object state or class state

Example

Instance method:

>>> obj = MyClass()
>>> obj.method()
('Instance method called', <__main__.MyClass at 0x7f7fd8365eb0>)

When the method is called, Python replaces the self argument with the instance object, obj.

Instance methods can also access the class itself through the self.__class__ attribute. $\rightarrow$ Instance methods can freely modify state on the object instance and on the class itself.

Class method:

>>> obj.classmethod()
('Class method called', __main__.MyClass)

The result shows us that it doesn’t have access to the <MyClass instance> object,but only to the <class MyClass> object, representing the class itself (everything in Python is an object, even classes themselves).

Static method:

>>> obj.staticmethod()
'static method called'

Static methods can neither access the object instance state nor the class state. They work like regular functions but belong to the class’ (and every instance’s) namespace.

Now let’s call these method on the class itself:

>>> MyClass.classmethod()
('Class method called', __main__.MyClass)

>>> MyClass.staticmethod()
'Static method called'

>>> MyClass.method()
---------------------------------------------------------------------------
TypeError Traceback (most recent call last)
Cell In [8], line 1
----> 1 MyClass.method()

TypeError: method() missing 1 required positional argument: 'self'

Attempting to call the instance method method() failed with a TypeError.

This is to be expected. As this time we didn’t create an object instance and tried calling an instance function directly on the class blueprint itself. This means there is no way for Python to populate the self argument and therefore the call fails with a TypeError exception.

When to Use `@classmethod`

Let’s say we have a Pizza class:

class Pizza:
 def __init__(self, ingredients):
 self.ingredients = ingredients

 def __repr__(self):
 return f"pizza ({self.ingredients!r})"

and want to creat various pizza objects:

Pizza(['mozzarella', 'tomatoes'])
Pizza(['mozzarella', 'tomatoes', 'ham', 'mushrooms'])
Pizza(['mozzarella'] * 4)

A nice and clean way to do that is by using class methods as factory functions for the different kinds of pizzas we can create:

class Pizza:
 def __init__(self, ingredients):
 self.ingredients = ingredients

 def __repr__(self):
 return f"pizza ({self.ingredients!r})"

 # Use classmethod as factory function to create different kinds of pizza

 @classmethod
 def margherita(cls):
 return cls(['mozzarella', 'tomatoes'])

 @classmethod
 def prosciutto(cls):
 return cls(['mozzarella', 'tomatoes', 'ham'])

Now we use the cls argument in the margherita and prosciutto factory methods instead of calling the Pizza constructor directly. Under the hood, these factory methods all use the same __init__ constructor internally and simply provide a shortcut for remembering all of the various ingredients.

This is a trick called Don’t Repeat Yourself (DRY) principle. The advantage is that if we decide to rename this class at some point, we won’t have to remember to update the constructor name in all of the factory functions.

Another way to look at this use of class methods is to realize that they allow you to define alternative constructors for your classes.

Python only allows one __init__ method per class.
Using class methods makes it possible to add as many alternative constructors as necessary. $\rightarrow$ This can make the interface for your classes self-documenting (to a certain degree) and simplify their usage.

When To Use `@staticmethod`

Static methods can’t access class or instance state because they don’t take a cls or self argument
- Using static methods is a great signal to show that particular methods are independent from everything else around them
- This restriction is also enforced by the Python runtime. It allows you to communicate clearly about parts of your class architecture so that new development work is naturally guided to happen within these boundaries. In practice, they often help avoid accidental modifications that go against the original design.
using static methods and class methods are ways to communicate developer intent while enforcing that intent enough to avoid most “slip of the mind” mistakes and bugs that would break the design.
Static methods also have benefits when it comes to writing test code.
- As static methods are completely independent from the rest of the class, we do NOT have to worry about setting up a complete class instance before we can test the method in a unit test. We can just fire away like we would if we were testing a regular function. $\rightarrow$ this makes future maintenance easier and provides a link between object-oriented and procedural programming styles.

Property

Sun, 12 Feb 2023 00:00:00 +0000

TL;DR

Use @property decorator for getters and setter in OOP in a more pythonic way.

Python programming provides us with a built-in @property decorator which makes usage of getter and setters much easier in Object-Oriented Programming. We will learn it step by step with an example.

The Temperature Example

Let us assume that we decide to make a class that stores the temperature in degrees Celsius. And, it would also implement a method to convert the temperature into degrees Fahrenheit.

The first naive solution is as follows:

class Celsius:
 def __init__(self, temperature=0):
 self.temperature = temperature

 def to_fahrenheit(self):
 return (self.temperature * 1.8) + 32

>>> human = Celsius()
>>> human.temperature = 37

>>> human.temperature
37

>>> human.to_fahrenheit()
98.60000000000001

whenever we assign or retrieve any object attribute like temperature as shown above, Python searches it in the object’s built-in __dict__ dictionary attribute as

print(human.__dict__)
# Output: {'temperature': 37}

Therefore, human.temperature internally becomes human.__dict__['temperature'].

Suppose we want to extend the usability of the Celsius class defined above. We know that the temperature of any object cannot reach below -273.15 degrees Celsius. An obvious solution to the above restriction will be to hide the attribute temperature (make it private) and define new getter and setter methods to manipulate it:

class Celsius:
 def __init__(self, temperature=0):
 self.set_temperature(temperature)

 def to_fahrenheit(self):
 return (self.get_temperature() * 1.8) + 32

 # getter method
 def get_temperature(self):
 return self._temperature

 # setter method
 def set_temperature(self, value):
 if value < -273.15:
 raise ValueError("Temperature below -273.15 is not possible.")
 self._temperature = value

>>> human = Celsius()
>>> print(human.get_temperature())
37

>>> print(human.to_fahrenheit())
98.60000000000001

>>> human.set_temperature(-300)
Traceback (most recent call last):
 File "<string>", line 30, in <module>
 File "<string>", line 16, in set_temperature
ValueError: Temperature below -273.15 is not possible.

However, the bigger problem with the above update is that all the programs that implemented our previous class have to modify their code from obj.temperature to obj.get_temperature() and all expressions like obj.temperature = val to obj.set_temperature(val). This refactoring can cause problems while dealing with hundreds of thousands of lines of codes!!!

→ All in all, our new update was not backwards compatible.

The `Property` class

A pythonic way to deal with the above problem is to use the property class.

We can update our code:

class Celsius:
 def __init__(self, temperature=0):
 self.temperature = temperature

 def to_fahrenheit(self):
 return (self.temperature * 1.8) + 32

 # getter
 def get_temperature(self):
 print("Getting value...")
 return self._temperature

 # setter
 def set_temperature(self, value):
 print("Setting value...")
 if value < -273.15:
 raise ValueError("Temperature below -273.15 is not possible")
 self._temperature = value

 # creating a property object
 temperature = property(get_temperature, set_temperature)

The last line of the code makes a property object temperature. Property attaches some code (get_temperature and set_temperature) to the member attribute accesses (temperature).

>>> human = Celsius(37)
Setting value...

>>> print(human.temperature)
Getting value...
37

>>> print(human.to_fahrenheit())
Getting value...
98.60000000000001

>>> human.temperature = -300
Setting value...
Traceback (most recent call last):
 File "<string>", line 31, in <module>
 File "<string>", line 18, in set_temperature
ValueError: Temperature below -273 is not possible

Any code that retrieves the value of temperature (including self.temperature) will automatically call get_temperature() instead of a dictionary (dict) look-up. Similarly, any code that assigns a value to temperature will automatically call set_temperature().

By using property, we can see that NO modification is required in the implementation of the value constraint. Thus, our implementation is backward compatible. 👏

The actual temperature value is stored in the private _temperature variable. The temperature attribute is a property object which provides an interface to this private variable.

More details

In Python, property() is a built-in function that creates and returns a property object. The syntax of this function is:

property(fget=None, fset=None, fdel=None, doc=None)

Here,

fget is function to get value of the attribute
fset is function to set value of the attribute
fdel is function to delete the attribute
doc is a string (like a comment)

A property object has three methods, getter(), setter(), and deleter() to specify fget, fset and fdel at a later point. This means, the line:

temperature = property(get_temperature,set_temperature)

can be broken down as:

# make empty property
temperature = property()

# assign fget
temperature = temperature.getter(get_temperature)

# assign fset
temperature = temperature.setter(set_temperature)

The `@property` Decorator

A more python (and also the more recommended) way is to use the @property decorator. We can even not define the names get_temperature and set_temperature as they are unnecessary and pollute the class namespace. For this, we reuse the temperature name while defining our getter and setter functions.

class Celsius:
 def __init__(self, temperature=0):
 self.temperature = temperature

 def to_fahrenheit(self):
 return (self.temperature * 1.8) + 32

 @property
 def temperature(self):
 print("Getting value...")
 return self._temperature

 @temperature.setter
 def temperature(self, value):
 print("Setting value...")
 if value < -273.15:
 raise ValueError("Temperature below -273 is not possible")
 self._temperature = value

Reference

Python @property decorator

OOP | Haobin Tan

Object Oriented Programming in Python and

OOP Basics

Class

Object

Methods

Inheritance

Encapsulation

Polymorphism

Reference

Operator Overloading

The Internals of Operations

Overloading Built-in Functions

len(): Gives a Length to Your Objects

str(): Prints Your Objects Prettily

repr(): Represents Your Objects

bool(): Makes Your Objects Truthy or Falsey

Overloading Built-in Operators

+: Makes Your Objects Capable of Being Added

Shortcuts: the += operator

[]: Indexes and Slices Your Objects

Reverse Operators: Makes Your Classes Mathematically Correct

Resource

Reference

Object Comparison: == vs is

String Conversion

__str__ vs. __repr__

Why Every Class Needs a __repr__

Define Your Own Exception Classes

Good Practice

Object Cloning

Shallow vs. Deep Copy

Shallow Copy

Example

Use Thecopy Module

Abstract Base Class (ABC)

Class vs Instance Variable

Class Variable vs. Instance Variable

Example

Instance, Class, and Static Methods

Instance vs. Class vs. Static Methods

When to Use @classmethod

When To Use @staticmethod

Property

The Temperature Example

The Property class

More details

The @property Decorator

Reference

`len()`: Gives a Length to Your Objects

`str()`: Prints Your Objects Prettily

`repr()`: Represents Your Objects

`bool()`: Makes Your Objects Truthy or Falsey

`+`: Makes Your Objects Capable of Being Added

Shortcuts: the `+=` operator

`[]`: Indexes and Slices Your Objects

`str` vs. `repr`

Why Every Class Needs a `repr`

Use The`copy` Module

When to Use `@classmethod`

When To Use `@staticmethod`

The `Property` class

The `@property` Decorator