Karim Aya

Karim Aya


Enforcing Single Responsibility Principle in Python

Single Responsibility Principle (or SRP) is one of the most important concepts in software development. The main idea of this concept is: all pieces of software must have only a single responsibility.

Why SRP is important? It is the main idea that stands behind software development. Decompose complex tasks to the set of simple building blocks to compose complex software from them back again. Just like we can compose lego or builtin functions:

print(int(input('Input number: ')))

This article will guide you through a complex process of writing simple code. I personally consider this article rather complicated and hard to percept if you do not have a solid background in python, so it is split into several parts:

  1. Definition of simple building block
  2. Problems with the functional composition in python
  3. Introduction to callable objects to solve functional composition problems
  4. Dependency injection reduces the boilerplate code of callable objects

It is okay to stop after each piece, revise it and to get to the latter one, because it will ensure you get the point, or at least first proof-readings showed so.

Please do not hesitate to suggest edits or to ask questions. This topic is not covered so well and I will be glad to clarify anything.

Defining building blocks

Let’s start with defining what are these “pieces of software” and “simplest building blocks” I am talking about?

The simplest building blocks are usually language’s expressions and statements. We can literally compose everything from it. But, we cannot fully rely on them since they are too simple. And we do not want to have repeated code all over the place. So we invent functions to abstract these simplest language constructs into something more meaningful that we can actually work with.

We expect these simplest building blocks (read “functions”) to be composable. And to be easily composable they must respect Single Responsibility Principle. Otherwise, we would have troubles. Because you can not compose things that do several things when you only need a part of them.

Functions can be complex too

Now, let’s make sure we can really rely on functions as simple building blocks.

We probably already know that functions can grow complex too and we have all seen absolutely unreadable functions like this one:

def create_objects(name, data, send=False, code=None):
data = [r for r in data if r[0] and r[1]]
keys = [‘{}:{}’.format(*r) for r in data]

existing_objects = dict(Object.objects.filter(
    name=name, key__in=keys).values_list('key', 'uid'))

with transaction.commit_on_success():
    for (pid, w, uid), key in izip(data, keys):
        if key not in existing_objects:
                if pid.startswith('_'):
                    result = Result.objects.get(pid=pid)
                    result = Result.objects.filter(
                        Q(barcode=pid) | Q(oid=pid)).latest('created')
            except Result.DoesNotExist:
                logger.info("Can't find result [%s] for w [%s]", pid, w)

                t = Object.objects.get(name=name, w=w, result=result)
                if result.container.is_co:
                    code = result.container.co.num
                    code = name_code
                t = Object.objects.create(
                    name=name, w=w, key=key,
                    result=result, uid=uid, name_code=code)


                if result.expires_date or (
                      and result.status in [Result.C, Result.W]):

            if not result.is_blocked and not result.in_container:
                if send:
                    if result.status == Result.STATUS1:

        elif uid != existing_objects[key] and uid:
            t = Object.objects.get(name=name, key=key)
            t.uid = uid
            t.name_code = name_code

It really works and powers someone’s production system. However, we can still say that this function definitely has more than one responsibility and should be refactored. But how do we make this decision?

There are different formal methods to track functions like this, including:

After we apply these methods it would be clear to us that this function is too complex. And we won’t be able to compose it easily. It is possible (and recommended) to go further and to automate this process. That’s how code-quality tools work with wemake-python-styleguide as a notable example.

Just use it. It will detect all the hidden complexity and will not allow your code to rot.

Here’s the less obvious example of a function that does several things and breaks SRP (and, sadly, things like that can not be automated at all, code reviews are the only way to find this kind of issues):

def calculate_price(products: List[Product]) -> Decimal:
“”“Returns the final price of all selected products (in rubles).”“”
price = 0
for product in products:
price += product.price

logger.log('Final price is: {0}', price)
return price

Look at this logger variable. How did it make its way into the function’s body? It is not an argument. It is just a hard-coded behavior. What if I do not want to log this specific price for some reason? Should I disable it with an argument flag?

In case I will try to do that, I will end up with something like this:

def calculate_price(products: List[Product], log: bool = True) -> …

Congratulations, we now have a well-known anti-pattern in our code. Do not use boolean flags. They are bad.

Moreover, how do I test this function? Without this logger.log call it would be a perfectly testable pure function. Something goes in and I can predict what will go out. And now it is impure. To test that logger.log actually works I would have to mock it somehow and assert that log was created.

You may argue that logger in python has a global configuration just for this case. But, it is a dirty solution to the same problem.

Such a mess just because of a single line! The problem with this function is that it is hard to notice this double responsibility. If we rename this function from calculate_price to proper calculate_and_log_price it would become obvious that this function does not respect SRP. And the rule is that simple: if “correct and full” function name contains andor, or then – it is a good candidate for refactoring.

Ok, this is all scary and stuff, but what to do with this case in general? How can we change the behavior of this function so it will finally respect SRP?

I would say that the only way to achieve SRP is composition: compose different functions together so each of them would do just one thing, but their composition would do all the things we want.

Let’s see different patterns that we can use to compose functions in python.


We can use the decorator pattern to compose functions together.

@log(‘Final price is: {0}’)
def calculate_price(…) -> …:

What consequences this pattern has?

  1. It not just composes, but glues functions together. This way you won’t have an ability to actually run just calculate_price without log
  2. It is static. You can not change things from the calling point. Or you have to pass arguments to the decorator function before actual function parameters
  3. It creates visual noise. When the number of decorators will grow – it would pollute our functions with a huge amount of extra lines

All in all, decorators make perfect sense in specific situations while are not suited for others. Good examples are: @login_required@contextmanager, and friends.

Functional composition

It is quite similar to the decorator pattern, the only exception is that it is applied in the runtime, not “import” time.

from logger import log

def controller(products: List[Product]):
final_price = log(calculate_price, message=‘Price is: {0}’)(products)

  1. With this approach, we can easily call functions the way we actually want to call them: with our without logpart
  2. On the other hand, it creates more boilerplate and visual noise
  3. It is hard to refactor due to the higher amount of the boilerplate and since you delegate composition to the caller instead of the declaration

But, it also works for some cases. For example, I use @safe function all the time:

from returns.functions import safe

user_input = input('Input number: ')

The next line won’t raise any exceptions:

safe_number = safe(int)(user_input)

You can read more about why exceptions might be harmful to your business logic in a separate article. We also provide a utility type-safe compose function in returns library that you might use for composing things at runtime.

Passing arguments

We can always just pass arguments. As easy as that!

def calculate_price(
products: List[Product],
callback=Callable[[Decimal], Decimal],
) -> Decimal:
“”“Returns the final price of all selected products (in rubles).”“”
price = 0
for product in products:
price += product.price

return callback(price)

And then we can invoke it:

from functools import partial

from logger import log

price_log = partial(log, ‘Price is: {0}’)
calculate_price(products_list, callback=price_log)

And it works great. Now our function does not know a thing about logging. It only calculates the price and returns the callback of it. We can now supply any callback, not just log. It might be any function that receives one Decimaland returns one back:

def make_discount(price: Decimal) -> Decimal:
return price * 0.95

calculate_price(products_list, callback=make_discount)

See? No problem, just compose functions the way you like. The hidden disadvantage of this method is in the nature of function arguments. We must explicitly pass them. And if the call-stack is huge, we need to pass a lot of parameters to different functions. And potentially cover different cases: we need callback A in case of a and callback B in case of b.

Of course, we can try to patch them somehow, create more functions that return more functions or pollute our code with @inject decorators everywhere, but I think that is ugly.

Unsolved problems:

  1. Mixed logic arguments and dependency arguments, because we pass them together at the same time and it hard to tell what is what
  2. Explicit arguments that can be hard or impossible to maintain if your call-stack is huge

To fix these problems, let me introduce you to the concept of callable objects.

Separating logic and dependencies

Before we start discussing callable objects, we need to discuss objects and OOP in general keeping SRP in mind. I see a major problem in OOP just inside its main idea: “Let’s combine data and behavior together”. For me, it is a clear violation of SRP, because objects by design do two things at once: they contain their state and have perform some attached behavior. Of course, we will eliminate this flaw with callable objects.

Callable objects look like regular objects with two public methods: init and call. And they follow specific rules that make them unique:

  1. Handle only dependencies in the constructor
  2. Handle only logic arguments in the call method
  3. No mutable state
  4. No other public methods or any public attributes
  5. No parent classes or subclasses

The straight-forward way to implement a callable object is something like this:

class CalculatePrice(object):
def init(self, callback: Callable[[Decimal], Decimal]) -> None:
self._callback = callback

def __call__(self, products: List[Product]) -> Decimal:
    price = 0
    for product in products:
        price += product.price
    return self._callback(price)

The main difference between callable objects and functions is that callable objects have an explicit step for passing dependencies, while functions mix regular logic arguments with dependencies together (you can already notice that callable objects are just a special case of a partial function application):

# Regular functions mix regular arguments with dependencies:
calculate_price(products_list, callback=price_log)

Callable objects first handle dependencies, then regular arguments:


But, given example do not follow all rules we impose on callable objects. In particular, they are mutable and can have subclasses. Let’s fix that too:

from typing_extensions import final

from attr import dataclass

@dataclass(frozen=True, slots=True)
class CalculatePrice(object):
_callback: Callable[[Decimal], Decimal]

def __call__(self, products: List[Product]) -> Decimal:

Now with the addition of @final decorator that restricts this class to be subclassed and @dataclass decorator with frozen and slots properties our class respects all the rules we impose in the beginning.

  1. Handle only dependencies in the constructor. True, we have only declarative dependencies, the constructor is created for us by attrs
  2. Handle only logic arguments in the call method. True, by definition
  3. No mutable state. True, since we use frozen and slots
  4. No other public methods or any public attributes. Mostly true, we cannot have public attributes by declaring slots property and declarative protected instance attributes, but we still can have public methods. Consider using a linter for this
  5. No parent classes or subclasses. True, we explicitly inherit from object and marking this class final, so any subclasses will be restricted

It now may look like an object, but it is surely not a real object. It can not have any state, public methods, or attributes. But, it is great for Single Responsibility Principle. First of all, it does not have data and behavior. Just pure behavior. Secondly, it is hard to mess things up this way. You will always have a single method to call in all the objects that you have. And this is what SRP is all about. Just make sure that this method is not too complex and does one thing. Remember, no one stops you from creating protected methods to decompose call behavior.

However, we have not fixed the second problem of passing dependencies as arguments to functions (or callable objects): noisy explicitness.

Dependency injection

DI pattern is widely known and used outside of the python world. But, for some reason is not very popular inside it. I think that this is a bug that should be fixed.

Let’s see a new example. Imagine that we have postcards sending app. Users create postcards to send them to other users on specific dates: holidays, birthdays, etc. We are also interested in how many of them were sent for analytic purposes. Let’s see how this use-case will look like:

from project.postcards.repository import PostcardsForToday
from project.postcards.services import (

@dataclass(frozen=True, slots=True)
class SendTodaysPostcardsUsecase(object):
_repository: PostcardsForToday
_email: SendPostcardsByEmail
_analytics: CountPostcardInAnalytics

def __call__(self, today: datetime) -> None:
    postcards = self._repository(today)

Next, we have to invoke this callable class:

# Injecting dependencies:
send_postcards = SendTodaysPostcardsUsecase(
SendPostcardsByEmail(email=SendGrid(‘username’, ‘pass’)),
CountPostcardInAnalytics(source=GoogleAnalytics(‘google’, ‘admin’)),

Actually invoking postcards send:


The problem is clearly seen in this example. We have a lot of dependencies-related boilerplate. Every time we create an instance of SendTodaysPostcardsUsecase – we have to create all its dependencies. Going all the way deep.

And all this boilerplate seems redundant. We have already specified all types of expected dependencies in our class. And transitive dependencies in our class’s dependencies, and so on. Why do we have to duplicate this code once again?

Actually, we don’t have to. We can use some kind of DI framework. I can personally recommend dependencies or punq. Their main difference is in how they resolve dependencies: dependencies uses names and punq uses types. We would go with punq for this example.

Do not forget to install it:

pip install punq

Now our code can be simplified so we won’t have to mess with dependencies. We create a single place where all the dependencies are registered:

# project/implemented.py

import punq

container = punq.Container()

Low level dependencies:


Intermediate dependencies:


End dependencies:


And then use it everywhere:

from project.implemented import container

send_postcards = container.resolve(SendTodaysPostcardsUsecase)

There’s literally no repeated boilerplate, readability, and type-safety out-of-the-box. We now do not have to manually wire any dependencies together. They will be wired by annotations by punq. Just type your declarative fields in callable objects the way you need, register dependencies in the container, and you are ready to go.

Of course, there are some advanced typing patterns for better Inversion of Control, but it is better covered in punq's docs.

When not to use callable objects

It is quite obvious that all programming concepts have their limitations.

Callable objects should not be used in the infrastructure layer of your application. Since there are too many existing APIs that do not support this kind of classes and API. Use it inside your business logic to make it more readable and maintainable.

Consider adding returns library to the mix, so you can get rid of exceptions as well.


We came a long way. From absolutely messy functions that do scary things to simple callable objects with dependency injection that respect Single Responsibility Principle. We have discovered different tools, practices, and patterns along the way.

But did our efforts make a big change? The most important question to ask yourself: is my code better after all this refactoring?

My answer is: yes. This made a significant change for me. I can compose simple building blocks into complex use-cases with ease. It is typed, testable, and readable.

Originally published by Nikita Sobolev at https://sobolevn.me/2019/03/enforcing-srp

Learn More

☞ Complete Python Bootcamp: Go from zero to hero in Python 3

☞ Complete Python Masterclass

☞ Learn Python by Building a Blockchain & Cryptocurrency

☞ Python and Django Full Stack Web Developer Bootcamp

☞ The Python Bible™ | Everything You Need to Program in Python

☞ Learning Python for Data Analysis and Visualization

☞ Python for Financial Analysis and Algorithmic Trading

☞ The Modern Python 3 Bootcamp


What is GEEK

Buddha Community

Enforcing Single Responsibility Principle in Python
Ray  Patel

Ray Patel


Lambda, Map, Filter functions in python

Welcome to my Blog, In this article, we will learn python lambda function, Map function, and filter function.

Lambda function in python: Lambda is a one line anonymous function and lambda takes any number of arguments but can only have one expression and python lambda syntax is

Syntax: x = lambda arguments : expression

Now i will show you some python lambda function examples:

#python #anonymous function python #filter function in python #lambda #lambda python 3 #map python #python filter #python filter lambda #python lambda #python lambda examples #python map

Shardul Bhatt

Shardul Bhatt


Why use Python for Software Development

No programming language is pretty much as diverse as Python. It enables building cutting edge applications effortlessly. Developers are as yet investigating the full capability of end-to-end Python development services in various areas. 

By areas, we mean FinTech, HealthTech, InsureTech, Cybersecurity, and that's just the beginning. These are New Economy areas, and Python has the ability to serve every one of them. The vast majority of them require massive computational abilities. Python's code is dynamic and powerful - equipped for taking care of the heavy traffic and substantial algorithmic capacities. 

Programming advancement is multidimensional today. Endeavor programming requires an intelligent application with AI and ML capacities. Shopper based applications require information examination to convey a superior client experience. Netflix, Trello, and Amazon are genuine instances of such applications. Python assists with building them effortlessly. 

5 Reasons to Utilize Python for Programming Web Apps 

Python can do such numerous things that developers can't discover enough reasons to admire it. Python application development isn't restricted to web and enterprise applications. It is exceptionally adaptable and superb for a wide range of uses.

Robust frameworks 

Python is known for its tools and frameworks. There's a structure for everything. Django is helpful for building web applications, venture applications, logical applications, and mathematical processing. Flask is another web improvement framework with no conditions. 

Web2Py, CherryPy, and Falcon offer incredible capabilities to customize Python development services. A large portion of them are open-source frameworks that allow quick turn of events. 

Simple to read and compose 

Python has an improved sentence structure - one that is like the English language. New engineers for Python can undoubtedly understand where they stand in the development process. The simplicity of composing allows quick application building. 

The motivation behind building Python, as said by its maker Guido Van Rossum, was to empower even beginner engineers to comprehend the programming language. The simple coding likewise permits developers to roll out speedy improvements without getting confused by pointless subtleties. 

Utilized by the best 

Alright - Python isn't simply one more programming language. It should have something, which is the reason the business giants use it. Furthermore, that too for different purposes. Developers at Google use Python to assemble framework organization systems, parallel information pusher, code audit, testing and QA, and substantially more. Netflix utilizes Python web development services for its recommendation algorithm and media player. 

Massive community support 

Python has a steadily developing community that offers enormous help. From amateurs to specialists, there's everybody. There are a lot of instructional exercises, documentation, and guides accessible for Python web development solutions. 

Today, numerous universities start with Python, adding to the quantity of individuals in the community. Frequently, Python designers team up on various tasks and help each other with algorithmic, utilitarian, and application critical thinking. 

Progressive applications 

Python is the greatest supporter of data science, Machine Learning, and Artificial Intelligence at any enterprise software development company. Its utilization cases in cutting edge applications are the most compelling motivation for its prosperity. Python is the second most well known tool after R for data analytics.

The simplicity of getting sorted out, overseeing, and visualizing information through unique libraries makes it ideal for data based applications. TensorFlow for neural networks and OpenCV for computer vision are two of Python's most well known use cases for Machine learning applications.


Thinking about the advances in programming and innovation, Python is a YES for an assorted scope of utilizations. Game development, web application development services, GUI advancement, ML and AI improvement, Enterprise and customer applications - every one of them uses Python to its full potential. 

The disadvantages of Python web improvement arrangements are regularly disregarded by developers and organizations because of the advantages it gives. They focus on quality over speed and performance over blunders. That is the reason it's a good idea to utilize Python for building the applications of the future.

#python development services #python development company #python app development #python development #python in web development #python software development

Art  Lind

Art Lind


Python Tricks Every Developer Should Know

Python is awesome, it’s one of the easiest languages with simple and intuitive syntax but wait, have you ever thought that there might ways to write your python code simpler?

In this tutorial, you’re going to learn a variety of Python tricks that you can use to write your Python code in a more readable and efficient way like a pro.

Let’s get started

Swapping value in Python

Instead of creating a temporary variable to hold the value of the one while swapping, you can do this instead

>>> FirstName = "kalebu"
>>> LastName = "Jordan"
>>> FirstName, LastName = LastName, FirstName 
>>> print(FirstName, LastName)
('Jordan', 'kalebu')

#python #python-programming #python3 #python-tutorials #learn-python #python-tips #python-skills #python-development

Art  Lind

Art Lind


How to Remove all Duplicate Files on your Drive via Python

Today you’re going to learn how to use Python programming in a way that can ultimately save a lot of space on your drive by removing all the duplicates.


In many situations you may find yourself having duplicates files on your disk and but when it comes to tracking and checking them manually it can tedious.

Heres a solution

Instead of tracking throughout your disk to see if there is a duplicate, you can automate the process using coding, by writing a program to recursively track through the disk and remove all the found duplicates and that’s what this article is about.

But How do we do it?

If we were to read the whole file and then compare it to the rest of the files recursively through the given directory it will take a very long time, then how do we do it?

The answer is hashing, with hashing can generate a given string of letters and numbers which act as the identity of a given file and if we find any other file with the same identity we gonna delete it.

There’s a variety of hashing algorithms out there such as

  • md5
  • sha1
  • sha224, sha256, sha384 and sha512

#python-programming #python-tutorials #learn-python #python-project #python3 #python #python-skills #python-tips

How To Compare Tesla and Ford Company By Using Magic Methods in Python

Magic Methods are the special methods which gives us the ability to access built in syntactical features such as ‘<’, ‘>’, ‘==’, ‘+’ etc…

You must have worked with such methods without knowing them to be as magic methods. Magic methods can be identified with their names which start with __ and ends with __ like init, call, str etc. These methods are also called Dunder Methods, because of their name starting and ending with Double Underscore (Dunder).

Now there are a number of such special methods, which you might have come across too, in Python. We will just be taking an example of a few of them to understand how they work and how we can use them.

1. init

class AnyClass:
    def __init__():
        print("Init called on its own")
obj = AnyClass()

The first example is _init, _and as the name suggests, it is used for initializing objects. Init method is called on its own, ie. whenever an object is created for the class, the init method is called on its own.

The output of the above code will be given below. Note how we did not call the init method and it got invoked as we created an object for class AnyClass.

Init called on its own

2. add

Let’s move to some other example, add gives us the ability to access the built in syntax feature of the character +. Let’s see how,

class AnyClass:
    def __init__(self, var):
        self.some_var = var
    def __add__(self, other_obj):
        print("Calling the add method")
        return self.some_var + other_obj.some_var
obj1 = AnyClass(5)
obj2 = AnyClass(6)
obj1 + obj2

#python3 #python #python-programming #python-web-development #python-tutorials #python-top-story #python-tips #learn-python