DEV Community: Michell Stuttgart

Using Literal Eval for String-to-Object Conversion in Python

Michell Stuttgart — Wed, 16 Oct 2024 12:34:50 +0000

literal_eval is an interesting function from Python's built-in library ast. This function evaluates a string representation of any Python expression and executes it.

Prerequisites

Basic knowledge of Python
Python version: 3.10

Examples

For example, let's convert the string "True" to the boolean value True:

import ast
value = ast.literal_eval('True')

print(value) # output: True
print(type(value)) # output: <type 'bool'>

This command can also handle more complex instructions, like list:

import ast

value = ast.literal_eval("[1, 2, 3]")

print(value) # output: [1, 2, 3]
print(type(value)) # output: <type 'list'>

and dict:

import ast

value = ast.literal_eval("{'a': 1, 'b': 1, 'c': 42}")

print(value) # output: {'a': 1, 'b': 1, 'c': 42}
print(type(value)) # output: <type 'dict'>

Differences between `eval` and `literal_eval`

The literal_eval function is similar to the well-known eval command, but it only accepts a limited set of Python structures: strings, numbers, dictionaries, lists, tuples, boolean values (True or False), or None.

The eval command is more powerful, but it can be dangerous if you don't control the strings it processes. For example, running the command eval('rm -rf /') on a Linux system (please, DO NOT run this command) would delete all files from the root of the operating system. However, if you pass the same string to the literal_eval function, it will perform a security check before executing it and will raise a ValueError exception.

>>> ast.literal_eval("__import__('os').system('rm -rf /')")
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/lib/python3.5/ast.py", line 84, in literal_eval
    return _convert(node_or_string)
  File "/usr/lib/python3.5/ast.py", line 83, in _convert
    raise ValueError('malformed node or string: ' + repr(node))
ValueError: malformed node or string: <_ast.Call object at 0x7f120ed568d0>

Conclusion

Despite the limitations on the types of structures accepted by literal_eval (which is not really an issue), it is recommended to use literal_eval instead of eval. The function's validation before executing an instruction can prevent many problems (as shown in the example above) and gives us better control over the code, as we know the types of structures it accepts as parameters.

References

ast - Abstract Syntax Trees — Python 3.10.15 documentation. https://docs.python.org/3.10/library/ast.html.

How to Merge Multiple Dictionaries with Python

Michell Stuttgart — Mon, 14 Oct 2024 21:24:09 +0000

In this tutorial, we'll explore how to create a dict, or dictionary, from one or more existing dictionaries in Python.

As usual in programming, there are several ways to achieve this.

I recently started to practice my writing in English. I apologize in advanced for any errors. :)

Prerequisites

Basic understanding of Python

Initial Approach

To begin, let's assume we have the following dictionaries:

dict1 = {
    'a': 1,
    'b': 2,
}

dict2 = {
    'b': 3,
    'c': 4,
}

For example, let's create a new dictionary called dictx using the values from dict1 and dict2 mentioned above. A common method to do this is by using the update method.

dictx = {}

dictx.update(dict1)
dictx.update(dict2)

So, dictx will be:

print(dictx)
# output: {'a': 1,'b': 3,'c': 4}

This method works well, but we have to call the update method for each dictionary we want to merge into dictx. Wouldn't it be interesting if we could pass all the dictionaries needed right when we create dictx?

Create a dictionary from multiple dictionaries

Python 3 introduced a very useful way to do this by using the ** operator.

dictx = {
 **dict1,
 **dict2,
}

print(dictx)
# output: {'a': 1,'b': 3,'c': 4}

A real copy of Dictionaries

When using the method described above, we need to keep a few things in mind. Only the first-level values will be copied into the new dictionary. For example, let's change the key 'a' present in both dictionaries and see if they have the same value:

dict1['a'] = 10
dictx['a'] = 11

print(dict1['a'])
# output: 10

print(dictx['a'])
# output: 11

We change the value of key 'a' in both dictionaries. However, this changes if one of the values in dict1 is a data structure, like a list, another dict, or a complex object. For example:

dict3 = {
    'a': 1,
    'b': 2,
    'c': {
        'd': 5,
    },
}

We have a dict object under the key 'c'. Now, let's create a new dict from it:

dictx = {
**dict3,
}

As in the previous example, we might think all the elements of dict3 are copied, but this isn't completely accurate. What actually happens is a shallow copy of dict3's values is made, meaning only the first-level values are duplicated. Let's see what happens when we change the value of the dictionary under the key 'c'.

dictx['c']['d'] = 11

print(dictx['c']['d'])
# output: 11

print(dict3['c']['d'])
# output: 11 (previous value was 5)

For the key 'c', it holds a reference to another data structure (a dict in this case). When we change any value in dict3['c'], it affects all dictionaries that were initialized with dict3. In other words, we need to be careful when creating a dictionary from others if they have complex values like list, dict, or other objects, as the attributes of these objects will not be duplicated.

To solve this issue, we can use the built-in dictionary method copy. Now, when we create dictx:

dict3 = {
    'a': 1,
    'b': 2,
    'c': {
        'd': 5,
    },
}

dictx = dict3.copy()

The copy method creates a shallow copy of each element in dict3, which helps solve our problem.

Here's another example:

dictx['c']['d'] = 11

print(dictx['c']['d'])
# output: 11

print(dict3['c']['d'])
# outuput: 5 (value has not been changed)

The values in dictx and dict3 are not equal because 'd' in dict3['c'] and dictx['c'] are references to different objects.

Conclusion

This article aims to simply demonstrate how to create dictionaries using some features the language offers, along with the pros and cons of each approach.

That's it.

Thanks for reading!

Understanding SOLID Principles: A Beginner's Guide

Michell Stuttgart — Mon, 14 Oct 2024 21:15:58 +0000

Every day, new requirements for our application arise, and we need to make improvements to meet them while keeping our code easy to read and maintain. If our application is built using Object-Oriented design, we can follow the SOLID principles to achieve this.

SOLID is an acronym for five principles of software design using Object-Oriented Programming (OOP). These principles are not linked to any specific programming language, so they work regardless of the language you use.

These principles were introduced by Robert C. Martin in a paper titled Design Principles and Design Patterns.

The acronym SOLID was later proposed by Michael Feathers and stands for:

Single Responsibility Principle
Open-Closed Principle
Liskov Substitution Principle
Interface Segregation Principle
Dependency Inversion Principle

These principles help software developers design and write Object-Oriented programs with low coupling and high cohesion. They also make it easier to maintain and refactor the code when needed.

Single Responsibility Principle

This principle states:

There should never be more than one reason for a class to change

We say that a class must be cohesive, meaning it should have only one responsibility.

Why is it a problem if a class has more than one responsibility?

When a class has multiple responsibilities, each one can change independently. This makes the class more coupled, meaning changes can have a bigger impact on other classes that inherit from it.

For example, let's look at the following code:

class Server: 

    def create_connection(self):
        pass

    def check_connection(self):
        pass

    def close_connection(self):
        pass

    def send_package(self):
        pass

    def receive_package(self):
        pass

In the Server class, we see it has two responsibilities: managing connections (create, close, and check) and managing data packages (send and receive). As a result, all classes that inherit from it also take on these two behaviors.

Applying the principle

Using the Single Responsibility Principle, we can split a class into two separate classes, each with its own responsibility: Connection managers and Package managers.

class ConnectionManager:
    """Manager connection only"""

    def create_connection(self):
        pass

    def check_connection(self):
        pass

    def close_connection(self):
        pass

class PackageManager:
    """Manager send and receive data packages only"""

    def send_package(self):
        pass

    def receive_package(self):
        pass

The Single Responsibility Principle is one of the hardest principles to apply because the idea of a class's responsibility can differ among software developers. They decide if a behavior fits within the class's scope. To apply this principle effectively, we should always focus on the problem we want to solve and the software architecture we use in our design.

Open-Closed Principle

We must always be careful when inheriting and changing class source code to avoid breaking code that already works. The Open-Close Principle helps us prevent this.

This principle states:

Software entities (classes, modules, functions, etc.) should be open for extension, but closed for modification.

Let's break down each part of this quote:

Open to extension means that a class's behavior can be expanded. We should be able to create a child class and extend a method to adjust its behavior based on the needs of our application.
Closed to modification means that a class's source code cannot be changed. No one is allowed to alter the original class's source code to meet new application requirements. Changing the class's source code can affect other functionalities that rely on this class's behavior.

For example, let's examine the following classes that represent the geometric shapes: square and circle

class Square:

    def __init__(self, lenght):
        super().__init__()
        self.lenght = lenght

class Circle:

    def __init__(self, radius):
        super().__init__()
        self.radius = radius

We also have a class that calculates the area of these shapes and returns the result.

import math

class ShapeAreaCalculator:

    def calc_area(self, shape):
        """Calculate area of shape"""

        area = 0

        if isinstance(shape, Square):
            area = shape.lenght ** 2

        elif isinstance(shape, Circle):
            area = math.pi * shape.radius ** 2

        return area

The problem with the ShapeAreaCalculator class is that whenever a new geometric shape is added, we need to add another if statement to check the shape. This increases the size and complexity of the calc_area method. In other words, the ShapeAreaCalculator class is not closed to modification.

Applying the principle

To start fixing the issue, let's enhance the geometric shape classes by creating a base class called Shape. This class will have a method named area, which will be extended by all geometric shapes that inherit from it.

class Shape:

    def area(self):
        pass

Let’s update the Square and Circle classes, make them inherit from Shape class.

class Square(Shape):

    def __init__(self, lenght):
        super().__init__()
        self.lenght = lenght

    def area(self):
        return self.lenght ** 2

import math

class Circle(Shape):

    def __init__(self, radius):
        super().__init__()
        self.radius = radius

    def area(self):
        return math.pi * self.radius ** 2

Now, every new geometric shape must inherit from the Shape class and implement its own area method.

All shape classes are now open to extension but closed to modification. This means they won't need changes when a new shape is added.

Finally, let's update the calc_area method so that it doesn't need changes when a new shape is added.

class ShapeAreaCalculator:

    def calc_area(self, shape):
        """Calcule area of shape"""
        area = shape.area()
        return area

This way, the calc_area method doesn't need changes, no matter how many new geometric shapes are added to our application.

Liskov Substitution Principle

This principle states:

Functions that use pointers or references to a base class must be able to use objects from derived classes without needing to know it.

It means that all children of our base class must have the same methods. If a class S is a child of class T, then all objects of class T can be replaced by objects of class S without needing to change our application.

Applying the principle

For example, consider a class named Shape. All classes that inherit from Shape must have an area method.

class Shape:

    def area(self):
        raise NotImplementedError("Subclasse should implement this")

When a class inherits from the Shape class, it must implement its own area method; otherwise, the application will raise a NotImplementedError.

Now, let's consider a class named ShapeAreaCalculator.

class ShapeAreaCalculator:

    def calc_area(self, shape):
        """Calcule area of shape"""
        return shape.area()

The calc_area method takes a shape object as a parameter without needing to know its specific class. We can substitute the shape object with any object from a child class of Shape, and the application will still function properly.

The Liskov Substitution Principle is a fundamental concept for implementing Polymorphism in object-oriented software.

Interface Segregation Principle

This principle states:

A class should never be forced to implement an interface or method that it will not use.

This situation usually occurs when we create classes or interfaces that are too generic, aiming to cover all possible uses of our application.

Applying the principle

For example, let's look at our Shape class:

class Shape:

    def area(self):
        raise NotImplementedError("Subclasse should implement this")

This class is usually used as the base class for Square and Circle classes, which are geometric shapes that implement the area method:

class Square(Shape):

    def __init__(self, lenght):
        super().__init__()
        self.lenght = lenght

    def area(self):
        return self.lenght ** 2

class Circle(Shape):

    def __init__(self, radius):
        super().__init__()
        self.radius = radius

    def area(self):
        return math.pi * self.radius ** 2

Now, let's say we want to enhance our Shape class to include 3D geometric shapes like cubes and spheres. To do this, we add a new method called volume to the Shape class.

class Shape:

    def area(self):
        raise NotImplementedError("Subclasse should implement this")

    def volume(self):
        raise NotImplementedError("Subclasse should implement this")

Consider the new method volume. All our child classes will need to implement it. However, it doesn't make sense for Square and Circle to have a volume method because they are 2D geometric shapes. They won't use it.

The Interface Segregation Principle advises us to add only methods that our classes will actually use. To solve this issue, let's create a new base class called Solid. This class will represent 3D geometric shapes, making it logical to include a volume method.

class Solid:

    def volume(self):
        raise NotImplementedError("Subclasse should implement this")

Dependency Inversion Principle

This principle states:

Only depend on abstractions, not on implementations.

In practical terms, no class should inherit from a concrete class, and no method should override an already implemented method. Our classes should always extend from interfaces or abstract classes.

Applying the principle

Take a look at the following classes:

class Shape:
    "Base class"

    def area(self):
        raise NotImplementedError("Subclasse should implement this")


class Square(Shape):
    "Square shape"

    def __init__(self, lenght):
        super().__init__()
        self.lenght = lenght

    def area(self):
        return self.lenght ** 2


class Circle(Shape):
    "Circle shape"

    def __init__(self, radius):
        super().__init__()
        self.radius = radius

    def area(self):
        return math.pi * self.radius ** 2

The Square and Circle classes override the area method of the Shape base class, which is an abstraction. We could make the Square class inherit from the Circle class.

class Square(Circle):

    def __init__(self, radius, lenght):
        super().__init__(radius)
        self.lenght = lenght

    def area(self):
        return self.lenght ** 2

This type of inheritance breaks the Dependency Inversion Principle because Circle is a concrete class. This approach leads to some problems:

Our Square class will have a radius attribute, which doesn't make any sense for the Square class since the attribute represents the radius of a circle. When creating a Square object, we will need to provide not only the length of the square's sides but also a value for radius, even though it will never be used.
We have to override the implementation of the area method from the Circle class, because if we don't, the Square class will use the area implementation from the parent Circle class, returning the wrong area calculation. This is because both the area formula and the value of the radius attribute (as seen in item 1) will be incorrect.

Based on the example above, we can conclude that we should always use abstract classes and interfaces whenever possible. This way, we avoid inheriting behaviors and attributes that are already implemented.

Conclusion

In conclusion, the SOLID principles offer a strong framework for designing and maintaining object-oriented software, with each principle focusing on a specific part of software design. By using these principles, developers can make their code less complex, improve readability, and make maintenance and scaling easier. Following SOLID principles leads to more reliable and efficient software development practices.

References

Martin, Robert C. (2014). "The Single Responsibility Principle". The Clean Code Blog
Martin, Robert C. (1996). "The Open-Closed Principle", C++ Report
Martin, Robert C. (March 1996). "The Liskov Substitution Principle" (PDF). C++ Report. Archived from the original (PDF) on 2015-11-28
Martin, Robert C. (June 1996). “The Interface Segregation Principle”. C++ Report
Martin, Robert C. (May 1996). “The Dependency Inversion Principle”. C++ Report

Create a dictionary from other dictionaries in Python

Michell Stuttgart — Fri, 17 May 2024 17:57:00 +0000

In this tutorial, the process of creating a dict , or dictionary, from one or more dictionaries in Python

As is customary in language, this can be done in several ways.

I recently started to practice my writing in English. I apologize in advanced for any errors. :)

Initial approach

To start, let's assume that we have the following dictionaries:

dict1 = {
    'a': 1,
    'b': 2,
}

dict2 = {
    'b': 3,
    'c': 4,
}

As an example, let's create a new dictionary called dictx with the values of dict1 and dict2 just above. A well-known approach is to use the method update.

dictx = {}

dictx.update(dict1)
dictx.update(dict2)

So we have to dictx will be:

print(dictx)
# output: {'a': 1,'b': 3,'c': 4}

This method works well, but we have to call the method update for each dictionary that we want to merge in dictx. It wouldn't be interesting if it were possible to pass all dictionaries needed already at the startup of dictx?

Create a dictionary from many dicts

Python 3 introduced a very useful way to do this, using operators **.

dictx = {
 **dict1,
 **dict2,
}

print(dictx)
# output: {'a': 1,'b': 3,'c': 4}

A real copy of dicts

When using the startup procedure above, we must have some factors in mind. Only the values of the first level will be duplicated in the new dictionary. As an example, let's change a key 'a' present in both dictionaries, and check if they have the same value:

dict1['a'] = 10
dictx['a'] = 11

print(dict1['a'])
# output: 10

print(dictx['a'])
# output: 11

We change the reference of key 'a' in both dictionaries. However, this changes when one of the values of dict1 is a data structure, like list, another dict, or some complex object. For example:

dict3 = {
    'a': 1,
    'b': 2,
    'c': {
        'd': 5,
    },
}

We have a dict object in key 'c'. Now, let's create a new dict from that:

dictx = {
**dict3,
}

As in the previous example, we can imagine a copy of all the elements of dict3, however, this is not entirely true. What happened is that a copy was made superficial of the values of dict3, that is, only the values of the first level were duplicated. Take a look at what happens when we change the value of the dictionary present in the key 'c'.

dictx['c']['d'] = 11

print(dictx['c']['d'])
# output: 11

print(dict3['c']['d'])
# output: 11 (previous value was 5)

In the case of the key 'c', it contains a reference to another data structure (a dict, in that case). When we change any value of dict3[ 'c' ], this reflects on all dictionaries that were initialized with dict3. In other words, we should pay attention when initializing a dictionary from others, when they have complex values, such as list, dict, or other objects (the attributes of this object will not be duplicated).

To get around this inconvenience, we can use the built-in Dictionary method copy. Now, when we start dictx:

dict3 = {
    'a': 1,
    'b': 2,
    'c': {
        'd': 5,
    },
}

dictx = dict3.copy()

The method copy performs a recursive copy of each element of dict3, solving our problem. See one more example:

dictx['c']['d'] = 11

print(dictx['c']['d'])
# output: 11

print(dict3['c']['d'])
# outuput: 5 (value has not been changed)

The values dictx and dict3 is not equal, because the 'd' of dict3['c'] and the dictx['c'] are references to distincts objects.

Conclusion

This article tries to demonstrate simply the creation of dictionaries, using some resources that the language offers and the pros and cons of each approach.

That's it.

'Thanks for reading!

DEV Community: Michell Stuttgart

Using Literal Eval for String-to-Object Conversion in Python

Prerequisites

Examples

Differences between eval and literal_eval

Conclusion

References

How to Merge Multiple Dictionaries with Python

Prerequisites

Initial Approach

Create a dictionary from multiple dictionaries

A real copy of Dictionaries

Conclusion

Understanding SOLID Principles: A Beginner's Guide

Single Responsibility Principle

Applying the principle

Open-Closed Principle

Applying the principle

Liskov Substitution Principle

Applying the principle

Interface Segregation Principle

Applying the principle

Dependency Inversion Principle

Applying the principle

Conclusion

References

Create a dictionary from other dictionaries in Python

Initial approach

Create a dictionary from many dicts

A real copy of dicts

Conclusion

Differences between `eval` and `literal_eval`