When writing unit tests, we sometime must mock functionalities in our system. In Python unittest.mock provides a patch functionality to patch modules and classes attributes. In this post, we will look at example of how to use patch to test our system in specific scenarios.

Few weeks ago we looked into CPython, the default implementation of Python. We saw that CPython is implemented in C and provides a way to declare extensions implemented in C to be used from Python. In this post we will look into a simple example of a module implemented in C and see how we can use it from the Python interpretor.

Application profiling allows developers to understand the performance and resource usage of an application. It can be used to identify hot paths or simply to explore what an application does. Today we will look at a way of capturing CPU samples for Python applications with py-spy and how to understand the resulting profiling data with speedscope.

During the development of a Python application, we interact with tools like pip and libraries like setuptools. Pip allows us to install packages while setuptools is a library built on top of distutils providing necessary tools to package and distribute our own application. Python supports two types of distributions, wheels and source distributions. In today’s post we will look at the usage of both of them and also look at how we can create them oursevles for our own application.

Last week we looked at CPython and mentioned that the interpretor was a stack based virtual machine. In today’s post we will go into more details why we mentioned that the VM was stack based by looking at the dissassembled Bytecode and compare it with a assembly code runnable on a register machine.

Last week we looked at how compilers worked in general. We saw that they were mostly composed of two parts, the front end and back end. The front end being the compiler from programming source code to intermediate representation and the back end being the runtime. In today’s post we will look specifically into how Python gets compiled and interpreted with the default implementation, CPython.

With the recent introduction of Apple M1 chip, we have seen the start of the adoption of the ARM processor architecture for Apple Macbook line. ARM being a different family of instruction set architecture than x86 (most common as of today), this means that any application built for x86 (for Mac with Intel or AMD chips) needs to be recompiled to run on ARM (M1 chip). The process of compilation is a multistep process starting taking code written in programming languages and transforming it into machine code understood by the processor. In today’s post we will look at the different part involved in the compilation process.

Few weeks ago we talked about Git Rebase. We saw how we could use it to manipulate the history of branches. By default, rebasing would flatten all merge commits making the history linear. In today’s post we will see how we can rebase while keeping merge commits.

The stash is the place where we can save work in progress from working tree and index while reverting to the HEAD commit, a command useful to pull latest on the checkout branch or simply inspect other branches. In this post we will look at how to use git stash.

Git log is a command used to look at the commit logs. It’s a useful command to look at the history of a repository, the different commits, the different merges or even the repository graph. In today’s post we will look at few example where git log can be used.

In few of our previous posts, we referred to the HEAD, working tree and index when dealing with Git. In today’s post we will look at what those mean with example.

Git cherry-pick is a command used to apply changes from an existing commit. In this post we’ll look at some example where cherry picking can be useful.

Visual Code ships with powerful Git support. In this post we will look at how we can use Visual Code as default diff and merge tool for Git.

Git reset is a command used to reset the current HEAD to a specified state. Common scenarios of using git reset are for clearing unstaged changes, reverting a staged commit or simply reverting a commit made by mistake back to the working tree. In this post we’ll look at Git reset with examples.

When using a branching mechanism like GitFlow or Mainline, we usually create pull request from short lived branches to long lived branches (e.g. develop, master). The pull request diff page gives a view of the changes that were brought by the branch. By default all repositories managers like GitHub, GitLab or Bitbucket uses “triple dot” diff to show diff. In this post we’ll look at the difference between “triple dot” and “double dot” diff.