SoFunction
Updated on 2025-04-25

Performance measurement and best practices of unpacking operations in Python

"To be honest, I've been writing Python for so many years, and it wasn't until one day I was cheated by a seemingly boring bug for two hours that I really realized:Unpacking operationThere are quite a lot of tricks hidden behind this little thing. ”

Today, let’s talk about Python’s unpacking operations, the details that you think you understand, but are actually almost there.

What is unpacking

Don't rush to take it away, this is not what you think"Oh! I'll see you early"The kind.

Let's have a simple example to warm up:

a, b = [1, 2]
print(a)  # 1
print(b)  # 2

This isThe most common unpacking operation. Python disassembles the list on the right and assigns the values ​​to the variables on the left.

but! Do you think it's just this little bit of fun? That's too underestimated.

Multi-layer unpacking: not just unpacking the "surface"

Once I was working on a nested data structure. I felt dizzy as I wrote it, and then suddenly I had an idea:

data = ("Sister Hua", (28, "Python Blogger"))

name, (age, title) = data
print(name)   #Rurururururururuprint(age)    # 28
print(title)  # Python blogger

This is actuallyMulti-layer unpacking, one team can handle it, professional and elegant.

But if you are still accessing with subscripts, it's a bit of a problem:

name = data[0]
age = data[1][0]
title = data[1][1]

This is not writing code, it is tormenting yourself.

Asterisk * Unpacking: Don't underestimate this "asterisk"

Many people know that it can be used on function parameters, such as:

def greet(*args):
    for arg in args:
        print(f"Hi {arg}")

greet("Sister Hua", "Reader Friends", "Little Black Cat")

But you may not notice it can be used inVariable assignmentsuperior:

first, *middle, last = [1, 2, 3, 4, 5]
print(first)   # 1
print(middle)  # [2, 3, 4]
print(last)    # 5

This is especially good when dealing with sequences of varying lengths, and those who have used it say"It's really fragrant"

Performance test of unpacking operations

As a technical blogger, I always feel that the article is not hard enough if it is unpredictable.

I made a small test:

import time

lst = list(range(1000000))

# Unpackingstart = ()
a, *b = lst
end = ()
print("Unpacking time consuming:", end - start)

# Slicestart = ()
a = lst[0]
b = lst[1:]
end = ()
print("Slicing time consuming:", end - start)

Running results:

Unpacking time: 0.007996559143066406
Slicing time: 0.01676344871520996

At this time, many people will come to the conclusion:"Hey? Then it seems that unpacking is faster than slicing!"

But, don’t worry, this conclusion is too early. Just like when someone’s WeChat avatar is a cat, he says he must be a cat-fetish expert. Maybe he is just too lazy to change his avatar.

Why does it feel like "slicing is slower than unpacking"? In fact, you were deceived by the illusion!

We did a performance test earlier, and the results showed that unpacking is faster

But don't rush to take sides, we have to figure it out-The essentially different things these two operations do!

Let's look at the comparison code:

# Unpackinga, *b = lst        # Take out the first element separately, and automatically package the rest into a list b
# Slicea = lst[0]
b = lst[1:]        # Take out the first element + manually slice to build a new list

Although it seems the same result on the surface, there are many things behind it:

operate What did behind the scenes
Unpacking The interpreter has been optimized, and the process of generating new lists is relatively efficient.
slice .copy()A sublist is required to allocate memory, copy elements and other operations

So, unpacking is a bit like "sneaking a little faster", but it's not how powerful it is,Python helped it to pick up some shortcuts

More rigorous testing methods are recommended

We just used it()The reference value of a rough round is actually limited. Come on, usetimeitTry a more scientific way:

import timeit

setup = "lst = list(range(1000000))"

print("Unpacking time consuming:", ("a, *b = lst", setup=setup, number=10))
print("Slicing time consuming:", ("a = lst[0]; b = lst[1:]", setup=setup, number=10))

If you run this test a few more times, you will find:

  • Unpacking may not always be fast, sometimes the gap is actually very small
  • The larger the data volume, the more obvious the overhead the slice replication is.

Let's summarize:

Unpacking vs. slices is not who "performance is stronger", but it depends on where you "use it".

1.Use unpacking:

  • To quickly disassemble the first or last item
  • No need to control the middle part very accurately
  • More like the simplicity of syntactic sugar

2. Use slices:

  • Need to process data for specific intervals
  • When particularly sensitive to performance
  • When the data structure is complex, the readability of unpacking decreases

A summary of one sentence:
Unpacking is suitable for "taking a little and leaving a bunch of them", and slicing is suitable for "precisely controlling which section to take".

Don't be fooled by the superficial time-consuming, just like I heard that Lao Wang next door earns 100,000 yuan a month for a side job, you can't just quit - you have to figure out what they are doing.

An overlooked pitfall

Tips: Time is up, and the following details are really something that many Python developers will ignore:

1. Unpacking cannot be more than the right variable

a, b = [1]
# ValueError: not enough values to unpack (expected 2, got 1)

Who hasn't encountered this error? When I saw it for the first time, I thought it was a bug in the editor. After restarting the IDE, I found out that it was my own dish.

2. The unpacking object must be iterable

a, b = None
# TypeError: cannot unpack non-iterable NoneType object

Don't ask me how I know, I almost smashed my keyboard when I debugged an empty return value that day.

3. The order of the dictionary unpacking is not what you think

a, b = {'x': 1, 'y': 2}
print(a, b)  # x y

You think the solution is the value, but in fact the solution is the key. Want to be worth it? have to.values()Ah Brother:

a, b = {'x': 1, 'y': 2}.values()
print(a, b)  # 1 2

Practical scenario: The actual usage of unpacking

Once I wrote a crawler and needed to extract fields from a list of tuples:

data = [
    ("Python", 95),
    ("Java", 85),
    ("Go", 75)
]

for lang, score in data:
    print(f"{lang} The score is {score}")

If you're still manuallydata[i][j], then you may really not understand Python's "elegance".

For example, if you exchange the values ​​of two variables, you should use temporary variables in the conventional way, right:

temp = a
a = b
b = temp

Python:

a, b = b, a

Seeing this, even my cat who usually only knows how to lie on the router to keep warm, screamed, "It's wonderful."

Unpacking + Function Parameters = God's Operation

You can use*and**Unpacking parameters:

def show(name, age):
    print(f"{name} - {age}")

args = ("Sister Hua", 28)
show(*args)

Dictionary is OK too:

kwargs = {"name": "Sister Hua", "age": 28}
show(**kwargs)

This thing works togethermap(), multi-threaded, coroutine operations, can be played with. Let's talk about it in detail next time, otherwise you have to say that I've been talking too much.

Let's summarize

To be honest, when I first learned Python, I thought it was "grammatical candy", but later I really slapped my face.

It is not just "convenient", but it can help you write it out more oftenClearer and more readable code. But don’t forget the performance issues and boundary conditions, otherwise “eating too much sugar will cause anger.”

This is the article about the performance measurement and best practices of unpacking operations in Python. For more related content on Python unpacking operations, please search for my previous articles or continue browsing the related articles below. I hope everyone will support me in the future!