I'm excited to share that I've completed a revision of the Flask Mega-Tutorial to keep it in line with new releases of Flask, Python and third-party dependencies.

To celebrate this update, you can purchase the paid version of this course with a $10 USD discount (this offer is valid through the rest of July 2021). If you are interested in this offer, use the FLASK2 promotional code at checkout, or click here to go directly to the order page with the coupon added. Thank you!

Rendering a table with data in a Flask template is a relatively simple task when the table is short, but can be incredibly hard for larger tables that require features such as sorting, pagination and searching. In this article I'm going to show you how to integrate the dataTables.js library in your templates, which will allow you to create fully featured tables with ease!

This is the fourth article in my series about working with a combined Flask and React project. In this part I'm going to cover how to deploy the application in Docker containers.

How can you update a part of a web page dynamically, without the user having to hit the refresh button on the browser?

This is a question that is frequently asked on the Internet. If you have some knowledge of JavaScript this is relatively easy to do, more so if you use a front end web framework such as React or Vue. But what if you have a standard web application written in Flask and Jinja templates?

In this article I'm going to introduce you to my Turbo-Flask extension, which will allow your Flask application to easily push asynchronous page updates to the browser, without having to write any JavaScript code. In the screenshot below, note how the CPU load numbers update without the user doing anything.

This is the second part of my series on unit testing Python applications. In this article I will introduce you to Conway's Game of Life, an interesting simulation that plays animated patterns on a grid.

My implementation of this game has an engine part, where the data structures and algorithm of the simulation are implemented, and a graphical user interface (GUI) part. In this article I will focus on testing the engine (testing GUIs will be covered in a future article).

Testing this code will present us with a few new challenges. In this article you will learn about the following topics:

• Test parametrization
• Building test matrices
• Basic mocking
• Testing Python exceptions

Today I'm starting a new series of articles about a topic that does not get a lot of coverage: how to write Python unit tests. Unlike other testing tutorials, I'm going to focus on testing techniques more than on the testing tools themselves. The idea is that in each part of this series I will look at a particular piece of code and discuss the challenges it presents from a testing point of view and how to address them.

In this first part I'm going to introduce the testing set up that I use in my projects, which is based on pytest. Then I will show you how to write unit tests for an implementation of the popular fizz buzz game that is frequently the subject of coding interview exercises.

The video below contains a complete 90 minute Socket.IO course using Python and JavaScript.

This is the list of chapters, each with a link to the code for each part of the tutorial:

When you learn Flask, you are told to create your Flask application instances by passing __name__ as the first argument to the Flask class. Most developers do this without thinking, and without knowing what it achieves.

In this article we are going to look at Flask(__name__) in depth. By the end you will not only have a full understanding of this pattern, but you will also know when to deviate from it and pass other values.

I'm often asked how to kill a background thread, and the answer to this question makes a lot of people unhappy: threads cannot be killed. In this article I'm going to show you two options we have in Python to terminate threads.

A couple of months ago there was an article titled Async Python is Not Faster making the rounds on social media. In it, the author Cal Paterson made the point that contrary to popular belief, asynchronous web frameworks are not only "not faster" than their traditional synchronous counterparts, but they are also slower. He supports this by showing the results of a fairly complete benchmark that he implemented.

I wish things were as simple as this author puts them in his blog post, but the fact is that measuring web application performance is incredibly complex and he's got a few things wrong, both in the implementation of the benchmark and in his interpretation of the results.

In this article you can see the results of my effort in understanding and fixing this benchmark, re-running it, and finally arriving at a shocking revelation.