Python: Building data abstractions
2026-02-21 02:49 Diff
https://hexlet.io/courses/python-data-abstraction/lessons/lists/theory_unit

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:

There's a little more code, but semantics is more important: each data element now has a name. Names are easier to use than indexes. That's why we recommend unpacking tuples into variables with talking names as soon as you need to work with the contents instead of the whole tuple. The code with the variable x or the reference point["x"] is easier to understand than the code with point[0].

Dictionaries look more informative when displayed on the screen. Imagine how segments represented in lists will look. As a list of lists:

It's impossible to understand that this is a segment without understanding the context. The only saving grace is good variable names, but this isn't enough.

Using the task-appropriate data structure is much more important:

Remember one simple rule: code that makes you think is not a great code. With this kind of code, you'll find non-obvious names, bad abstractions, incorrect data structures, and a strong dependence on context. It is important to remember that light code isn't simple code.

Using a dictionary immediately gives another vital advantage — extensibility. A tuple does not mind a list used as a fragile structure. It is impossible to swap the value of the arguments — the whole code that counts on an order will break, or you'll have to rewrite everything.

You can't expand it just like that either: part of the code, of course, will continue to work, but part of it may break — for example, x, y = point. Using a dictionary doesn't rely on the order of keys and certainly doesn't depend on how many there are. You can add a new key, and the program will almost certainly remain functional.

What other data should be represented by dictionaries? Any single entity:

  • User
  • Course
  • Lesson
  • Payment
  • Chess game, in addition to the date, names, and place, it also contains a set of moves