Common beginner mistakes in Python

July 22, 2019

Common beginner mistakes in Python

Python, being a high-level and dynamic programming language, is famously easy to use. This has contributed to it being wildly popular and growing in recent years. The ease of use also comes with ease of misuse. We've put together a list of common mistakes that beginners can do when writing code in Python.

1. Unnecessary lambda expression

Functions are first-class citizens in Python. This means you can assign it to some variable, pass it as an argument in another function invocation, and so on. This can be counter-intuitive for beginners, or developers coming from other programming languages.

A common example of this pattern is: {{< highlight python "hl_lines=4" >}} def request(self, method, **kwargs): # ... if method not in ("get", "post"): req.get_method = lambda: method.upper() # ... {{< /highlight >}}

The recommended way to write this is: {{< highlight python "hl_lines=4" >}} def request(self, method, **kwargs): # ... if method not in ("get", "post"): req.get_method = method.upper # ... {{< /highlight >}} (example)

2. Raising NotImplemented

This is one of those examples where similar naming can confuse developers. NotImplementedError is an exception class that should be raised when derived classes are required to override a method. NotImplemented is a constant which is used to implement binary operators. When you raise NotImplemented, a TypeError will be raised.

Incorrect: {{< highlight python "hl_lines=3" >}} class SitesManager(object): def get_image_tracking_code(self): raise NotImplemented {{< /highlight >}}

Correct: {{< highlight python "hl_lines=3" >}} class SitesManager(object): def get_image_tracking_code(self): raise NotImplementedError {{< /highlight >}} (examples)

3. Mutable default argument

Default arguments in Python are evaluated once when the function definition is executed. This means that the expression is evaluated only once when the function is defined and that the same value is used for each subsequent call. So if you are modifying the mutable default argument — a list, dict, etc., it will be modified for all future calls.

Incorrect: {{< highlight python "hl_lines=1" >}} def add_item(new_item, items=[]): items.append(new_item) {{< /highlight >}}

Correct: {{< highlight python "hl_lines=1" >}} def add_item(new_item, items=None): if items is None: items = [] items.append(new_item) {{< /highlight >}} (example)

4. Using assert statement as guarding condition

Since assert provides an easy way to check some condition and fail execution, it's very common for developers to use it to check validity. But when the Python interpreter is invoked with the -O (optimize) flag, the assert statements are removed from the bytecode. So, if assert statements are used for user-facing validation in production code, the block won't be executed at all — potentially opening up a security vulnerability. It is recommended to use assert statements only in tests.

Incorrect: {{< highlight python >}} assert re.match(VALID_ADDRESS_REGEXP, email) is not None {{< /highlight >}}

Correct: {{< highlight python >}} if not re.match(VALID_ADDRESS_REGEXP, email): raise AssertionError {{< /highlight >}} (example)

5. Using isinstance in place of type

Either type or isinstance can be used to check the type of an object in Python. But there is an important difference — isinstance takes care of inheritance while resolving the type of object, while type does not. So sometimes using isinstance might not be what you want to use. Take a look at the following example:

{{< highlight python >}} def which_number_type(num): if isinstance(num, int): print('Integer') else: raise TypeError('Not an integer')

which_number(False) # prints 'Integer', which is incorrect {{< /highlight >}}

Here, Since bool is a subclass of int in Python, isinstance(num, int) is also evaluated as True, which is not the expected behavior. In this particular case, using type is the correct way. Read more about the difference in the behavior of these two methods here.

Get started with DeepSource

DeepSource is free forever for small teams and open-source projects. Start analyzing your code in less than 2 minutes.

Choose an account
Newsletter

Read product updates, company announcements, how we build DeepSource, what we think about good code, and more.