In the previous lesson, we said that a tuple is the easiest way to represent a point. But is this the right way? Why not take, say, a list? Let's figure it out.
When we talk about language constructs, we consider syntax and semantics, meaning what tasks we solve with the design. In practice, people often use tools for other purposes. It leads to the creation of code that's more difficult to understand, debug, and maintain.
A list is a collection, a set of some values of the same type, implying the possibility of iteration and identical processing. In addition, these values are not rigidly related to each other and can exist independently. The list often lacks positionality — rigidly fixed places for its values. Either the position depends on the specific task.
Here are some real-life examples where lists fit. The order is important here:
- List of safewords
- List of users
- List of lessons in a course
- List of chess moves
When applied to our graphic library, lists are suitable, for example, for storing collections of points or sets of segments. The point itself is not a collection. It is a single whole because the parts of it make no sense by themselves. We cannot establish relations between them, unlike in users' lists.
The code that works with a particular item represented by a list always expects the list to consist of two elements with their positions. In other words, the list is used as a structure to describe a composite object. We describe it by several values — two coordinate numbers in this case.
A tuple as a structure with a fixed composition of elements is much better suited for representing points: the tuple elements don't change their positions or become more or less. But tuples are not the only option for representing entities.
If you need to represent the same points and segments, you can use a dictionary:
point = {"x": 2, "y": 3}
symmetrical_point = {
"x": -point["x"],
