10.4 C
Tuesday, April 2, 2024

5 Frequent Python Gotchas (And How To Keep away from Them)

5 Common Python Gotchas (And How To Avoid Them)
Picture by Creator


Python is a beginner-friendly and versatile programming language recognized for its simplicity and readability. Its elegant syntax, nonetheless, just isn’t resistant to quirks that may shock even skilled Python builders. And understanding these is important for writing bug-free code—or pain-free debugging if you’ll.

This tutorial explores a few of these gotchas: mutable defaults, variable scope in loops and comprehensions, tuple project, and extra. We’ll code easy examples to see why issues work the best way they do, and in addition have a look at how we are able to keep away from these (if we really can 🙂). 

So let’s get began!



In Python, mutable defaults are widespread sharp corners. You’ll run into sudden habits anytime you outline a perform with mutable objects, like lists or dictionaries, as default arguments. 

The default worth is evaluated solely as soon as, when the perform is outlined, and never every time the perform known as. This will result in sudden habits if you happen to mutate the default argument inside the perform.

Let’s take an instance:

def add_to_cart(merchandise, cart=[]):
    return cart


On this instance, add_to_cart is a perform that takes an merchandise and appends it to a listing cart. The default worth of cart is an empty record. Which means calling the perform with out an merchandise so as to add returns an empty cart. 

And listed here are a few perform calls:

# Consumer 1 provides objects to their cart
user1_cart = add_to_cart("Apple")
print("Consumer 1 Cart:", user1_cart)  



This works as anticipated. However what occurs now?

# Consumer 2 provides objects to their cart
user2_cart = add_to_cart("Cookies")
print("Consumer 2 Cart:", user2_cart) 


Output >>>

['Apple', 'Cookies'] # Consumer 2 by no means added apples to their cart!


As a result of the default argument is a listing—a mutable object—it retains its state between perform calls. So every time you name add_to_cart, it appends the worth to the identical record object created through the perform definition. On this instance, it’s like all customers sharing the identical cart.


How To Keep away from


As a workaround, you possibly can set cart to None and initialize the cart contained in the perform like so:

def add_to_cart(merchandise, cart=None):
    if cart is None:
        cart = []
    return cart


So every person now has a separate cart. 🙂

For those who want a refresher on Python capabilities and performance arguments, learn Python Perform Arguments: A Definitive Information.



Python’s scope oddities name for a tutorial of their very own. However we’ll have a look at one such oddity right here.

Have a look at the next snippet:

x = 10
squares = []
for x in vary(5):
    squares.append(x ** 2)

print("Squares record:", squares)  

# x is accessible right here and is the final worth of the looping var
print("x after for loop:", x)


The variable x is about to 10. However x can also be the looping variable. However we’d assume that the looping variable’s scope is restricted to the for loop block, sure?

Let’s have a look at the output:

Output >>>

Squares record: [0, 1, 4, 9, 16]
x after for loop: 4


We see that x is now 4, the ultimate worth it takes within the loop, and never the preliminary worth of 10 we set it to.

Now let’s see what occurs if we substitute the for loop with a comprehension expression:

x = 10
squares = [x ** 2 for x in range(5)]

print("Squares record:", squares)  

# x is 10 right here
print("x after record comprehension:", x)


Right here, x is 10, the worth we set it to earlier than the comprehension expression:

Output >>>

Squares record: [0, 1, 4, 9, 16]
x after record comprehension: 10


How To Keep away from


To keep away from sudden habits: For those who’re utilizing loops, be certain that you don’t identify the looping variable the identical as one other variable you’d need to entry later.



In Python, we use the is key phrase for checking object identification. Which means it checks whether or not two variables reference the identical object in reminiscence. And to verify for equality, we use the == operator. Sure?

Now, begin a Python REPL and run the next code:

>>> a = 7
>>> b = 7
>>> a == 7
>>> a is b


Now run this:

>>> x = 280
>>> y = 280
>>> x == y
>>> x is y


Wait, why does this occur? Properly, this is because of “integer caching” or “interning” in CPython, the usual implementation of Python.

CPython caches integer objects within the vary of -5 to 256. Which means each time you utilize an integer inside this vary, Python will use the identical object in reminiscence. Subsequently, if you examine two integers inside this vary utilizing the is key phrase, the result’s True as a result of they confer with the identical object in reminiscence.

That’s why a is b returns True. You too can confirm this by printing out id(a) and id(b).

Nonetheless, integers exterior this vary will not be cached. And every incidence of such integers creates a brand new object in reminiscence. 

So if you examine two integers exterior the cached vary utilizing the is key phrase (sure, x and y each set to 280 in our instance), the result’s False as a result of they’re certainly two totally different objects in reminiscence.


How To Keep away from


This habits shouldn’t be an issue until you attempt to use the is for evaluating equality of two objects. So at all times use the == operator to verify if any two Python objects have the identical worth.



For those who’re aware of built-in knowledge buildings in Python, you already know that tuples are immutable. So that you can’t modify them in place. Information buildings like lists and dictionaries, however, are mutable. Which means you can change them in place.

However what about tuples that include a number of mutable objects?

It is useful to began a Python REPL and run this straightforward instance:

>>> my_tuple = ([1,2],3,4)
>>> my_tuple[0].append(3)
>>> my_tuple
([1, 2, 3], 3, 4)


Right here, the primary component of the tuple is a listing with two components. We strive appending 3 to the primary record and it really works wonderful! Properly, did we simply modify a tuple in place?

Now let’s attempt to add two extra components to the record, however this time utilizing the += operator:

>>> my_tuple[0] += [4,5]
Traceback (most up-to-date name final):
  File "", line 1, in 
TypeError: 'tuple' object doesn't assist merchandise project


Sure, you get a TypeError which says the tuple object doesn’t assist merchandise project. Which is predicted. However let’s verify the tuple: 

>>> my_tuple
([1, 2, 3, 4, 5], 3, 4)


We see that components 4 and 5 have been added to the record! Did this system simply throw an error and succeed on the identical time?

Properly the += operator internally works by calling the __iadd__() methodology which performs in-place addition and modifies the record in place. The project raises a TypeError exception, however the addition of components to the tip of the record has already succeeded. += is maybe the sharpest nook!


How To Keep away from


To keep away from such quirks in your program, strive utilizing tuples solely for immutable collections. And keep away from utilizing mutable objects as tuple components as a lot as doable.



Mutability has been a recurring subject in our dialogue so far. So right here’s one other one to wrap up this tutorial.

Typically you might have to create impartial copies of lists. However what occurs if you create a replica utilizing a syntax much like list2 = list1 the place list1 is the unique record?

It’s a shallow copy that will get created. So it solely copies the references to the unique components of the record. Modifying components by way of the shallow copy will have an effect on each the unique record and the shallow copy. 

Let’s take this instance:

original_list = [[1, 2, 3], [4, 5, 6], [7, 8, 9]]

# Shallow copy of the unique record
shallow_copy = original_list

# Modify the shallow copy
shallow_copy[0][0] = 100

# Print each the lists
print("Unique Checklist:", original_list)
print("Shallow Copy:", shallow_copy)


We see that the adjustments to the shallow copy additionally have an effect on the unique record:

Output >>>

Unique Checklist: [[100, 2, 3], [4, 5, 6], [7, 8, 9]]
Shallow Copy: [[100, 2, 3], [4, 5, 6], [7, 8, 9]]


Right here, we modify the primary component of the primary nested record within the shallow copy: shallow_copy[0][0] = 100. However we see that the modification impacts each the unique record and the shallow copy. 


How To Keep away from


To keep away from this, you possibly can create a deep copy like so:

import copy

original_list = [[1, 2, 3], [4, 5, 6], [7, 8, 9]]

# Deep copy of the unique record
deep_copy = copy.deepcopy(original_list)

# Modify a component of the deep copy
deep_copy[0][0] = 100

# Print each lists
print("Unique Checklist:", original_list)
print("Deep Copy:", deep_copy)


Now, any modification to the deep copy leaves the unique record unchanged.

Output >>>

Unique Checklist: [[1, 2, 3], [4, 5, 6], [7, 8, 9]]
Deep Copy: [[100, 2, 3], [4, 5, 6], [7, 8, 9]]



And that’s a wrap! On this tutorial, we have explored a number of oddities in Python: from the shocking habits of mutable defaults to the subtleties of shallow copying lists. That is solely an introduction to Python’s oddities and is certainly not an exhaustive record. You’ll find all of the code examples on GitHub.

As you retain coding for longer in Python—and perceive the language higher—you’ll maybe run into many extra of those. So, maintain coding, maintain exploring!

Oh, and tell us within the feedback if you happen to’d prefer to learn a sequel to this tutorial.

Bala Priya C is a developer and technical author from India. She likes working on the intersection of math, programming, knowledge science, and content material creation. Her areas of curiosity and experience embody DevOps, knowledge science, and pure language processing. She enjoys studying, writing, coding, and occasional! At the moment, she’s engaged on studying and sharing her information with the developer group by authoring tutorials, how-to guides, opinion items, and extra. Bala additionally creates participating useful resource overviews and coding tutorials.

Latest news
Related news


Please enter your comment!
Please enter your name here