DEV Community: Pedro S

Organizing your code: 3 ways to create namespaces in Python

Pedro S — Wed, 09 Dec 2020 15:09:06 +0000

You've written your script and then you noticed that it is a single file with 30 functions, 5 global variables, some main instructions. This is difficult to skim and, in consequence, difficult to read and edit in the future. You should separate all your code into sections: first you can try and make some big comments, but the code may still look dense after that; this means it is time to create some namespaces.

A namespace is an environment in which symbols have a unique meaning. In Python and many other programming languages in the C tradition, one function makes a namespace (for most uses, also called a "scope"): the variables declared in its body won't be accessible outside of it, unless you explicitly allow that -- which is considered a bad style. There are other ways to create a namespace, and making use of that is a great idea to organize your code; and it is not me saying that, it is Tim Peters:

Sparse is better than dense.
(...)
Namespaces are one honking great idea -- let's do more of those!
-- The Zen of Python, by Tim Peters

Let's see some ways to create namespaces. Aiming for modularity is a good practice in any programming languages; the following examples are in Python, but I can see them being applied very similarly in JavaScript and other languages too.

The file system way: modules

This is what people usually think about first when planning on creating namespaces.

If you import any module (except when using from ... import *, which is not recommended most of the times), the objects exported by that module will be available in dot notation:

import itertools

for letter in itertools.cycle('ABCD'):
    ...

cycle('ABCD') # NameError: name 'cycle' is not defined

In the code snippet, the itertools module was imported and is only accessed with the itertools symbol. You could make your own function called cycle, and that would be different from itertools.cycle. The most important, though, is that you can split your project into different files and organize code like this:

def get_movie_posters():
    ...

def download_poster():
    ...

def parse_poster_response():
   ...

def get_movie_ratings():
   ...

movie_posters = get_movie_posters()
movie_ratings = get_movie_ratings()

def analyze_movies(posters, ratings):
   ...

analyze_movies(movie_posters, movie_ratings)

As this:

import posters
import ratings
import analyzer

analyzer.run(posters.get(), ratings.get())

For that, you need to distribute the code into different files. Assuming the snippet above is in a main.py file you want to run, your folder structure could be:

project/
  main.py
  analyzer.py
  ratings.py
  posters.py

It is necessary that the modules you create do not have the same name as a module in the standard library. It is also possible to create subfolders, as long as all of them have a __init__.py (it can just be an empty file with that name), as well as execute the project folder as a whole (we would call that a "package"). For more details, check the documentation.

It may happen, however, that you are not free to create extra files. Despite that, it is still possible to have multiple namespaces in a single script by using the solutions below. The code may not become shorter, but it would at least be more organized.

The OOP-inspired way: classes

Python classes work pretty much as plain namespaces:

from abc import ABC
from typing import final

@final
class PostersNamespace(ABC):

    @staticmethod
    def get():
        ...

    @staticmethod
    def _download_poster():
        ...

    @staticmethod
    def _parse_poster_response():
       ...

You can have objects shared between the functions in the class, but not necessarily with the rest of the code:

from abc import ABC
from typing import final

@final
class PostersNamespace(ABC):

    url = 'https://www.postersite.com'

    @classmethod
    def get(cls):
        return cls.url

PostersNamespace.get() # https://www.postersite.com
PostersNamespace.url # https://www.postersite.com
url # NameError: name 'url' is not defined

I call this "OOP-inspired" (and not just "OOP") because we are using classes only for their namespace-like behavior in Python - they are not being used as a template for an object, so they should not be instantiated (that's why we are inheriting from ABC in the snippets above) or be used as a parent class (that's why we are annotating the classes as @final¹).

You could achieve a similar effect with dictionaries, but it is not as easy/organized to insert functions with multiple statements into them:

postersNamespace = {
    "get": lambda: ... # You either rely on lambda functions only...
    "download_poster": download_poster # ...or use a function defined elsewhere,
                                       # but then the namespace won't be very delimited visually
}

Of course, you can also go full OOP and make those classes more than mere namespaces and actually initialize objects out of them:

class Poster:

    url = 'https://www.postersite.com'

    @staticmethod
    def __init__(self, movie):
        ...

movies = [...]
posters = [Posters(movie) for movie in movies]

This, however, requires you to manage the state of more objects -- and take care so that the code doesn't become spaghetti again.

The functional way: closures

In Python, you can create functions inside of functions. Make use of that to separate sections in your code:

def posters():

    url = 'https://www.postersite.com'

    def _download_poster():
        ...

    def _parse_poster_response():
        ...

    ...
    return posters

Differently from the OOP-style solution, this limits the access you have to the different objects in the namespace, as you're restricted to the returned object. One work-around is to make functions return other functions (which will still have access to the original scope):

def make_get_poster_function():

    url = 'https://www.postersite.com'

    def _download_poster():
        ...

    def _parse_poster_response():
        ...

    def get_poster(movie):
        r = requests.get(url)
        ...

    return get_poster

In the snippet above, the function returned by make_get_poster_function() is able to be executed successfully, as the reference to "url" inside of it goes along with it when it is returned.

Conclusion

These are tips to make a single script more organized - maybe by splitting it into multiple scripts, maybe by separating the code it contains into different namespaces defined inside of it. Managing a big number of namespaces (something that invariably occurs in large applications) requires you to go some steps further and carefully plan the architecture you will follow. This is a separate topic that raises questions on the restraints posed by the stack you want to use and personal preferences. As a starting point to one architectural style I personally like, see this post by Dan Haiduc.

Cover image by engin akyurt on Unsplash

The @final decorator does not prevent inheritance during runtime, only during static type checking (when using Mypy, for example). Python does not provide a way to totally prevent a class from inheriting from another one; you can only simulate that with custom dunder methods (see here and here). ↩

TypeScript: adjusting types in reduce function with an async callback

Pedro S — Mon, 23 Nov 2020 13:59:44 +0000

This took me some type of debugging after not finding a StackOverflow answer that addressed the exact same issue I had, so I thought it would be nice to register my solution.

In TypeScript, I was using the Array.prototype.reduce() method to iterate on an array and populate an object based on an asynchronous function, like this:

function makeObject(keys: string[]) {
  return keys.reduce(async (acc, key) => {
    acc[key] = await asyncFunc(key);
    return acc;
  }, {})
}

Trying to fix the error

The transpiler complained about the third line, when setting a property to acc:

Element implicitly has an 'any' type because expression of type 'string' can't be used to index type '{}'.
No index signature with a parameter of type 'string' was found on type '{}'.

As far as I got this, this happened because the {} object has no type annotation at all, so the acc variable in the callable function would be identified with the any type.

First, I tried to fix it like this:

function makeObject(keys: string[]) {
  return keys.reduce(async (acc, key) => {
    acc[key] = await asyncFunc(key);
    return acc;
  }, <Record<string, string[]>>{})
}

No success; now, there's an error in the declaration of the callback function:

No overload matches this call.
Overload 1 of 3, '(callbackfn: (previousValue: string, currentValue: string, currentIndex: number, array: string[]) => string, initialValue: string): string', gave the following error.
Argument of type '(acc: Record, key: string) => Promise>' is not assignable to parameter of type '(previousValue: string, currentValue: string, currentIndex: number, array: string[]) => string'.
Types of parameters 'acc' and 'previousValue' are incompatible.
Type 'string' is not assignable to type 'Record'.
Overload 2 of 3, '(callbackfn: (previousValue: Record, currentValue: string, currentIndex: number, array: string[]) => Record, initialValue: Record): Record<...>', gave the following error.
Argument of type '(acc: Record, key: string) => Promise>' is not assignable to parameter of type '(previousValue: Record, currentValue: string, currentIndex: number, array: string[]) => Record'.
Type 'Promise>' is not assignable to type 'Record'.
Index signature is missing in type 'Promise>'.

Well, this looks scary. But this basically means that the transpiler:

First tried to match the type of acc with the string type of the elements in the keys array. This doesn't make sense in my function, because I'm providing an initial value and returning it from the callback, so the acc variable will never directly receive an element in the array.
Then there's a second option (a second "overload"): the return value of my callback function should match the type of acc, which is what the function returns. As the callback is an asynchronous function, it always returns a Promise, and acc is not a Promise, it is a Record<string, string[]>. So I have to change the return value to a promise, and that is the rule for every async function in TypeScript.

(I'm curious about overload 3 of 3 not showing up.)

Next attempt:

function makeObject(keys: string[]) {
  return keys.reduce(async (acc, key) => {
    acc[key] = await asyncFunc(key);
    return acc;
  }, <Promise<Record<string, string[]>>>{})
}

Again, no luck with assigning the new property to acc:

Element implicitly has an 'any' type because expression of type 'string' can't be used to index type 'Promise>'.
No index signature with a parameter of type 'string' was found on type 'Promise>'.

The issue is that the type of acc is, now, a full Promise. It makes no sense to plainly add a new property to it; it is like doing this:

>> let aPromise = Promise.resolve({})
<- undefined

>> aPromise['newProp'] = 'hey'
<- 'hey'

>> aPromise
<- Promise { <state>: "fulfilled", <value>: {} }

>> aPromise.newProp
<- 'hey'

The value of the Promise is still empty: I never assigned newProp to it, I only did it to the Promise wrapper.

Solution

This did the trick:

function makeObject(keys: string[]) {
  return keys.reduce(async (acc, key) => {
    const values = await asyncFunc(key);
    acc.then(obj => obj[key] = values);
    return acc;
  }, Promise.resolve(<Record<string, string[]>>{}))
}

This satisfies all the conditions:

The async callback function is returning a Promise, as it is supposed to be;
I am assigning a property to the value of the Promise, and the value is an object with a specific type (Record<string, string>).

As the Promise is resolved since the beginning, the function inside the acc.then(...) call is guaranteed to always run.

Types are fun.

When to use OOP in Python if you are not developing large applications

Pedro S — Mon, 20 Jul 2020 02:50:56 +0000

Having started studying programming from a data science perspective, I had a lot of trouble understanding not exactly what object-oriented programming (OOP) was, but why should I use it. After all, the code I wrote seemed to do just well without custom classes and objects.

Inspired by an introduction on OOP in Python I watched in a recent online conference (in Brazilian Portuguese) – congrats on the talk, Maria Clara! –, I decided to write an introduction to OOP that will not focus on syntax or Python perks (I will assume you already know fairly well how to declare classes in Python), but will actually focus on when OOP should be used. I will present: (1) to what kind of code and issues OOP was created, (2) whether it has a place in non-complex applications and (3) what features Python has that can be used besides ordinary class declarations for most of the projects.

Why OOP in the first place?

OOP was developed as a strategy to organize code in large and complex applications.

Let's say we are making an application in a bank that will read the balance of an account from a database and decrease it under request of a user, if there are enough funds. It could follow this very simplified layout:

from db_connection import db_connection

def get_balance(db_connection, account_no):
    ...
    return balance

def withdraw(balance, amount):
    if amount <= balance:
        return balance - amount
    else:
        raise Exception('Insufficient funds')

def update_balance(db_connection, account_no, new_balance):
    ...

if __name__ == '__main__':
    account_no = input('Type account number: ')
    to_withdraw = float(input('Type amount to be withdrawn: '))
    old_balance = get_balance(db_connection, account_no)
    new_balance = withdraw(old_balance, to_withdraw)
    update_balance(db_connection, account_no, new_balance)

What if we want to allow a certain category of bank accounts to withdraw more money than available in the balance under a certain interest rate, as a loan? Our code quickly becomes way more complex:

from db_connection import db_connection

ACCOUNT_CATEGORIES_ALLOWED_TO_LOAN = set(...)

def get_balance(db_connection, account_no):
    ...
    return balance

def get_account_category(db_connection, account_no):
    ...
    return account_category

def withdraw(balance, amount, is_allowed_to_loan):
    if not is_allowed_to_loan and amount > balance:
        raise Exception('Insufficient funds')
    else:
        return balance - amount

def update_balance(db_connection, account_no, new_balance):
    ...

def register_loan(db_connection, account_no, amount_loaned):
    ...

if __name__ == '__main__':
    # Get account info
    account_no = input('Type account number: ')
    to_withdraw = float(input('Type amount to be withdrawn: '))
    acct_category = get_account_category(db_connection, account_no)
    # Withdrawal operation
    old_balance = get_balance(db_connection, account_no)
    is_allowed_to_loan = acct_category in ACCOUNT_CATEGORIES_ALLOWED_TO_LOAN
    new_balance = withdraw(old_balance, to_withdraw, is_allowed_to_loan)
    # Updates
    update_balance(db_connection, account_no, new_balance)
    if new_balance < 0:
        register_loan(db_connection, account_no, new_balance)

Now imagine that there could be many different bank account categories, each of them with different consequences for different operations and available funds. The code base would quickly become spaghetti code: a bunch of different functions and flow control statements that is difficult to understand and to maintain.

That is where OOP steps in. It associates a specific set of data with specific functions to act on them, in a way that the relation between the information your code is dealing with and what it is able to do with it is very clear. Let's check how this is done.

Abstraction

Code in OOP is organized through abstractions of real-life objects. In this sense, the bank account in our application example would be a class, a "thing" with its own characteristics (the data, called "attributes" in OOP) and actions (the "methods"), just like it is in the real world:

class Account:
    def __init__(self, balance):
        self.balance = balance

    def withdraw(self, amount):
        if amount <= self.balance:
            self.balance -= amount
        else:
            raise Exception('Insufficient funds')

Just from taking a quick look at the snippet above, you can know that (1) every account has a certain balance (2) every account can receive a "withdraw" action. This is different from what we had in our previous spaghetti application: if we were to change anything regarding bank accounts in our system, we would have to search through all the code to find where the changes should be made – and we would have to hope that we were making the change in all the necessary places. Classes help everything be more concentrated.

Our application could now be simplified to this:

from db_connection import db_connection
from classes.accounts import Account

def get_account(db_connection, account_no) -> Account:
    ...
    return Account(balance)

def update_database(db_connection, account_obj: Account):
    ...

if __name__ == '__main__':
    account_no = input('Type account number: ')
    to_withdraw = float(input('Type amount to be withdrawn: '))
    account = get_account(db_connection, account_no)
    account.withdraw(to_withdraw)
    update_database(db_connection, account)

Notice that all the actions related to changing the data related to the account (ie, the account's state) is not present in this script anymore. The act of withdrawing money can now be all in a separate script where the definition of the Account class is - a package called "classes", with a script called "accounts.py", for example. Any change related to what happens when money is withdrawn from an account should be made in that separate script; any change related to how a user withdraws money (what information is requested, for example), should be made in our main script.

If you paid attention to the type annotations, you may have noticed that the database-related functions now deal with Account objects directly. This makes it easier if, in addition to withdrawing money, we also want the user to be able to call other methods from the Account class - that would just require the addition of some more lines, with no need to instantiate new objects.

Encapsulation

Our Account class can have its balance easily edited during runtime. If we do account.balance = 0.0005, the balance would change, even though that would be a strange amount for an ordinary account in dollars.

That is why it is recommended that the attributes of a class be encapsulated, ie, hidden from the outside world (the rest of the code). In Python, this can be done with the help of the @property decorator (or, alternatively, with the convention of naming attributes with leading underscores¹):

class Account:
    def __init__(self, balance):
        self.balance = balance

    def withdraw(self, amount):
        if amount <= self.balance:
            self.balance -= amount
        else:
            raise Exception('Insufficient funds')

    @property
    def balance(self):
        # Nothing special about getting the balance;
        # we will just return it.
        return self._balance

    @balance.setter
    def balance(self, new_value):
        # When changing the balance, however,
        # we want to enforce certain rules
        if (new_value * 100) % 1 > 0:
            raise Exception('Balance can only have up to two decimal houses')
        else:
            self._balance = new_value

Now, any time that the balance attribute of the Account class is set up with no respect to the rules defined in the Account class itself, an exception is raised:

>>> acct = Account(55.663)
...
Exception: Balance can only have up to two decimal houses

Encapsulation allows the implementation of the attributes to be reserved to the code of the class itself. Instead of checking in our main script if the new balance is a valid value, this action is reserved to the class declaration. Again, this results in a more organized code.

Inheritance

Inheritance is a nice feature of OOP that allows classes to be related to each other. When one class inherits another, all the attributes and the methods of the class it is inheriting from are automatically attached to it, with no code repetition being necessary. In our bank application, this allows different Account types to be easily implemented, as a different HighIncomeAccount type, for example:

class HighIncomeAccount(Account):
    pass

Just the lines of code above are enough to create a different data structure that has the same attributes and methods of the main Account class (and is recognized as an instance of it, although "indirectly", in practice), at the same time it can be recognized as an object of a different type:

>>> simple_account = Account(55)
>>> high_income_account = HighIncomeAccount(99955)
>>> all(hasattr(acct, 'withdraw')
...     for acct in (simple_account, high_income_account))
True
>>> isinstance(high_income_account, Account)
True
>>> type(simple_account) is type(high_income_account)
False

In our application, we would have to change our get_account function to create either an Account or a HighIncomeAccount object depending on the case. However, besides that change, the rest of the code would be able to continue calling account.withdraw in the same way as before. This is how OOP programs are seen to work: as "messages" (such as the withdraw order) being transmitted from one part of the code to another.

Polymorphism

Inheritance can be better used in our application by taking advantage of polymorphism: the same method can produce different results depending on which object it is called. We can, for example, change how withdraw works for a HighIncomeAccount:

class HighIncomeAccount(Account):
    def withdraw(self, amount):
        diff = self.balance - amount
        if diff >= 0:
            super().withdraw(amount)
        else:
            self.amount_loaned = diff
            self.balance = diff

That way, the exception regarding insufficient funds is raised only on Account objects, but not on HighIncomeAccount objects:

>>> simple_account = Account(55)
>>> high_income_account = HighIncomeAccount(99955)
>>> simple_account.withdraw(99999999)
...
Exception: Insufficient funds
>>> high_income_account.withdraw(99999999)
>>> high_income_account.balance
-99900044

And, once again, our main script representing the user interaction can remain unchanged (besides the database interactions, which should be updated to consider the new amount_loaned attribute). All the logic regarding the bank accounts is concentrated in the classes definition. The code base as a whole is, therefore, much easier to read and maintain.

Using OOP in simpler applications

All the above makes a lot of sense if you are dealing with code for complex systems. It is a different reality, however, if you write code for exploratory data analysis, for example, which is much more objective: given a certain dataset, tasks are executed one after another in order to provide certain insights (results). In this case, classes may not be necessary, as your code may not have to deal with different data structures. If everything is a DataFrame and all your functions can act on any DataFrame, there is not much reason to waste your time creating classes and declaring different methods. Much of the features of OOP, such as inheritance and polymorphism, in fact, would just not be useful at all.

As a rule of thumb, creating custom classes is useful when you have the need to associate specific data and actions. That was the case in the application example above: we needed a way to associate a "balance" with a certain "withdraw" action. As a different example, it can also be useful if we are building a scraper that collects information from different sources or in different ways, as the scraper of a hospitals database that also looks for the distance between one hospital and another and checks a different database for the number of beds in the hospital:

class Hospital():
    def __init__(self, address):
        self.address = address
        self.beds_no = self.get_number_of_beds()

    def get_number_of_beds(self):
        ...
        return beds_no

    def get_distance(self, to: 'Hospital'):
        ...
        return distance

Using such a class in your program can make information be transmitted much more easily between different parts of your code. It is clearer and shorter to call Hospital.get_distance(to=another_hospital) when necessary than to retrieve an address, call a separate function like get_distance(from=one_address, to=another_address) and deal with scattered information.

Another good application of data and actions being put together is when you need a different custom data type. In Python, data types such as list and dict can be seen as classes with special methods - as any other class, you can inherit from them and change their behavior. Let's say you need a list that only accepts instances of a dict, and you need to be sure of that, for any obscure reason. Then you can be creative and do:

class ListOfDicts(list):
    def __init__(self):
        # We will not accept iterables as an argument to the constructor,
        # or else ListOfDicts({'a': 'dict'}) will result in ['a'].
        super()

    def append(self, item):
        self._execute_if_is_dict(super().append, item)

    def insert(self, idx, obj):
        self._execute_if_is_dict(super().insert, idx, obj)

    def __setitem__(self, item):
        self._execute_if_is_dict(super().__setitem__, item)

    def _execute_if_is_dict(self, action, *args):
        if not isinstance(args[-1], dict):
            raise Exception('Only dicts are accepted as items')
        else:
            action(*args)

This approach should only be used if you are really sure of which methods you need to override. It shows, however, how Python can be flexible. If you ever catch yourself asking what if a certain data type could behave in a specific way, do some research: it is probable that someone has already written a custom class that does exactly what you need.

Beyond classes: useful data structures

You may be tempted to create a class to encapsulate a simple set of information, for example:

>>> class Person:
...     def __init__(self, name, age, address):
...         self.name = name
...         self.age = age
...         self.address = address
>>> holmes = Person('Sherlock Holmes', 60, '221B Baker Street')

Do not do it this way for simple data structures like this one. You can aggregate data like that in a simple dict, and that will not raise questions regarding the possibility of any special method being attached to your Person class – which is, actually, very simple:

>>> holmes = {
...     'name': 'Sherlock Holmes',
...     'age': 60,
...     'address': '221B Baker Street'
... }

This will equally allow you to retrieve information from the "holmes" object in a very direct way. It is true, however, that you may need a template, ie, a way of ensuring that every possible Person have three different attributes associated with it: a name, an age, and an address. That is the use case of a NamedTuple.

Named tuples

A named tuple is, like a tuple, an immutable ordered collection. However, its items can be retrieved based on a named index, just like in a dict. In the end, they are like an immutable dict that must be created from a specific template:

>>> from collections import namedtuple
>>> Person = namedtuple('Person', ['name', 'age', 'address'])
>>> holmes = Person('Sherlock Holmes', 60, '221B Baker Street')

Instantiating an object from a named tuple is very similar to instantiating an object from a custom class. Accessing the attributes is also done with dot notation and, besides all that, printing the object will exhibit a user-friendly representation:

>>> holmes.age
60
>>> print(holmes)
Person(name='Sherlock Holmes', age=60, address='221B Baker Street')

Data classes

Named tuples may present issues in some applications:

A named tuple can be compared as equal to another that carries the same fields. The holmes object we created could be considered equal to a named tuple Character(name='Sherlock Holmes', age=60, address='221B Baker Street'), for example;
In the same way, a named tuple is also considered equal to a tuple carrying the same fields: holmes == ('Sherlock Holmes', 60, '221B Baker Street') returns True.
Named tuples are iterable. Part of your code may iterate on a Person named tuple and expect it to return a name, an age and then an address; if you add a different field to the named tuple definition (a country attribute, for example), you may break this other part unwillingly.
You may want to change the values of an attribute in the named tuple. However, as tuples are immutable, that is not possible.
You may want more complexity. Maybe you want to query Wikipedia before creating your holmes object, and then save the resulting link to the named tuple itself. This is not possible, as you cannot change the methods underlying the named tuple (unless you create a new custom class yourself).
Composing the attributes in a named tuple based on other named tuples (as if doing class inheritance) is complicated and may result in obscure code.

These issues require a complex data structure - which is solved with the use of classes. However, much of the work related to the creation of a class to hold different attributes was made easier in Python 3.7 with the addition of the @dataclass decorator (see the documentation and the discussion reported in PEP 557). Its basic use eliminates some of the boilerplate necessary when creating a class, at the same time it adds a lot of advanced functionality for when you need something more complex than both a dict and a named tuple:

from dataclasses import dataclass, field

@dataclass
class Person:
    name: str
    age: int
    address: str
    wikipedia_page: str = field(init=False, repr=False)

    def __post_init__(self):
        self.wikipedia_page = get_wikipedia_page(self.name)

def get_wikipedia_page(query):
    ...
    return page_address

The code above is equivalent to this one:

class Person:
    def __init__(self, name: str, age: int, address: str):
        self.name = name
        self.age = age
        self.address = address
        self.wikipedia_page: str = get_wikipedia_page(self.name)

    def __repr__(self):
        attrs_dict = vars(self)
        attrs_dict.pop('wikipedia_page')
        attrs_as_str = ', '.join(f'{k}={v.__repr__()}' for k, v in attrs_dict.items())
        return f'{type(self).__name__}({attrs_as_str})'

def get_wikipedia_page(query):
    ...
    return page_address

What the @dataclass decorator does is to look for the class variables that contain a type annotation and make both a __init__ constructor and a __repr__ method with them. There is also extra functionality: the field function, for example, is telling the decorator that this field should be taken care of by the __post_init__ function and that it should not show up in the __repr__ result. The dataclass class also contains extra functionality that allows for a finer control of how the object will be instantiated (see the options of the class constructor and the field function), compared to others (see eq and order parameters of the constructor) and transformed into different data types (asdict and astuple methods) or in just a different object with different fields (replace method). This is a good amount of fine tuning in a much simpler code structure, as seen from the reduction of lines above.

Conclusion

OOP does not have much space in simple, procedural programs. When necessary, however, they can add a lot of functionality to your data structures at the same time they can make code that is easier to scale and maintain. For everyday scripting (as in much of data science tasks), a dict, a named tuple or the simplification provided by the @dataclass decorator are all good alternatives to the creation of a custom class if there is no necessity of putting together specific data and functions.

Let me know your thoughts and comments. This is my first article on programming and any criticism is very appreciated 😄

What do you think about OOP when not building complex applications? Do you think functional programming or other programming styles can scale just as well?

Cover image by Ross Sneddon on Unsplash.

Check the use of single and double leading underscores here: https://dbader.org/blog/meaning-of-underscores-in-python. This is a convention adopted in PEP8, the style guide of the Python language: https://www.python.org/dev/peps/pep-0008/. ↩