It’s been a long time since I’ve updated my blog- applying to and then joining university has been fun and interesting, but time has been rather limited. However, I’ve recently taken up learning a skill that I have found to be very exciting and worth writing about – coding.

Of course, coding isn’t something that immediately comes to mind when one looks at a blog related to life science. I myself believed (until about six months ago) that coding and an understanding of Machine Learning (ML) wasn’t required for someone going into medicine. However, I realised that that is a rather foolish approach to take- ML has already begun to revolutionise healthcare in ways we couldn’t have possibly imagined.

Thus, I decided to try to learn Python. This was about six months ago, and while I have learned a great deal, I know that there is a long way to go till I’ll be proficient in the language. This isn’t the first time I’ve tried to learn how to code – I did do a small project around two years ago (I wrote about that as well – link) but it was basic and I didn’t really get motivated enough to explore further. It’s different this time – I am really motivated!

And now to my project. I have made a program that will be able to predict pneumonia by looking at chest X-rays with reasonable accuracy. Since this was my first project, I did come across countless little problems that took time to solve. One particular issue I’ll be talking about later took me two weeks to resolve! But that’s the great thing really- not only did I learn and explore different areas of Python and PyTorch (the python library I used for predictions) but also learned how to handle errors.

This project is catered towards students studying medicine/healthcare related fields. The reason why I’ve used transfer learning is that you don’t need to actually create a model by writing countless lines of code- you can simply import and apply ResNet50 (a Deep Convolutional Neural Network (CNN)) in a very simple and efficient manner. I’ve also talked a bit more about how I feel ML might impact healthcare, so if that’s something you find particularly interesting feel free to scroll down to the penultimate section.

The first step – importing libraries, data preparation and augmentation

The first step is to import our libraries. You might have to download these using the command !pip install library_name if you aren’t working on Colab.

Another thing to look at is that I’m using the library PyTorch. PyTorch is one of three main libraries made for neural networks (the other two are Tensorflow and Keras). I’ve chosen PyTorch primarily because it is more explainable – it’s easier to understand how the code works and how the model makes its decisions (this is the main reason why PyTorch is more prevalent in academia/research). Keras and Tensorflow are, however, said to be more powerful than PyTorch.

Explainability is particularly important in medicine. We have these amazing, powerful algorithms and we know that they can give us some great results. However, we still aren’t sure about how these algorithms work, make decisions or make predictions. This lack of clarity has led to such algorithms being termed as ‘black-box’ algorithms, and has also resulted in a general feeling of distrust with regards to results obtained from these algorithms. Doctors may tend to disregard results obtained by ML because they cannot understand how it arrived at that result (indeed, no one really can!). You can improve explainability by making your code easier to understand, including graphs and using Python libraries such as LIME and SHAP to indicate features of an image that make most impact in the model’s final prediction.

Data preparation is perhaps the most important part of the entire project – real world data is seldom in perfectly usable form. It needs to be ‘transformed’ into a particular format for it to be useful.

I unzipped and downloaded the dataset into my google drive, mounted the drive to Google Colab and specified the path (the path to the file is essentially a map for the program to follow to find the dataset).

This dataset (https://www.kaggle.com/paultimothymooney/chest-xray-pneumonia/) is split into three parts – a training set (5216 images), a testing set (624 images) and a validation set (16 images). It’s a fairly popular dataset.

We transform all these images by resizing, rotating, cropping and normalizing pixel values. Here’s the code-

But why do we even resize, crop and rotate our images? We do this to prevent ‘overfitting’. Simply put, if we train our model on the same dataset too many times, our model will begin to memorize the data given to it. It will be extremely adept at predicting labels for our training set. However, it’ll be largely ineffective at predicting the correct label for our testing dataset – our model has gotten used to the same dataset. Cropping, resizing and rotating our images randomly make them unidentical to the previous dataset, thus reducing the likelihood of overfitting.

Now you might ask, what does normalizing mean? 

All images are composed of pixels. A pixel has three RGB (red, green and blue) colour channels each with a certain intensity (ranging from 0-255). These three channels come together to give the pixel a certain colour.

In order to make computation more efficient and avoid extreme pixel values from disrupting image analysis, we normalize by fitting all pixel values in the range of 0 to 1. The mean and standard deviation values given in the above code are default for all grayscale images.

Let’s look at some images now. I’ve defined a function print_img that can display these images (keep in mind that cv2 can’t display images very easily in Colab).

One can clearly see the difference between the two X-rays. The first image (index=0) has a relatively clean and dark chest with ribs one to six (anteriorly) visible. However, the 3000th image (index=3001) is filled with fluid, indicated by white colour occupying most of the left lung on the X-ray.

We’re done with data transformation but we aren’t quite ready yet to use this data. Our training set has 3875 images of pneumonia and just 1341 normal images. If we decided to use this as our training set our model would become biased in favour of pneumonia. We have to make out training set a bit more ‘fairer’.

If you looked at the code carefully you might have noticed that we created a train_set2, which is essentially the training set with slight modifications. The trick is to take just the normal images in train_set2 and add them in our main training set. This is the code I used to do that-

Another issue is that our validation set is far too small. I’ll elaborate on this set’s usefulness later, but briefly, the validation set is used to determine how well our model is performing while we are training it. It helps us fine tune our model and reach optimal prediction capacity. With just sixteen images, we aren’t going to get much benefit using a validation set – we have to increase it’s size.

Our training set right now has 6557 images. Let’s use part of this set as our validation set-

Now we have 5245 training images and 1312 validation set images. Large enough!

Finally, when dealing with large amounts of data it is always a good idea to supply images to the model in batches- we can’t give our model 5245 images to train all at once. We pass batches of images one by one to our model. Batch sizes vary, but it’s recommended to use a batch size which is a power of two.

But wait. How does a CNN even work?

Understanding Convolutional Neural Networks (CNN) is relatively difficult. I found a resource that explains it amazingly well- https://towardsdatascience.com/intuitively-understanding-convolutions-for-deep-learning-1f6f42faee1

Let’s take the example of a hypothetical grayscale 2D image. This image has 25 pixels (5 x 5) and each pixel has some intensity. We also have a 3 x 3 kernel with certain weights that ‘slides’ over this 2D image. It fits into each 3 x 3 section of our 2D image, multiplies each pixel of the image with it’s own corresponding value and adds all 9 values up to form one pixel.

Confused? Here’s an extremely useful animation that should clear things up (credit to https://arxiv.org/abs/1603.07285 )-

Okay, so how does this help with our predictions? Let’s imagine this 2D image which displays a chest X-ray. The model will pass a kernel over the image and produce an output feature map. Initially, our model had to deal with 25 parameters (in form of 25 pixel intensities). By passing the kernel over this image, this model now has to consider 9 parameters instead of 25. this new feature map of 9 pixels is a weighted sum of the original image.

Let’s assume we had 10 different 2D images all with pneumonia. After looking at each image the model will be able to identify commonalities and particular features that will appear in images containing Pneumonia. Perhaps it’s a certain pixel which will have an intensity value above 0.8 if the image had pneumonia. These relationships and identifying features will be determined by our model itself (this is the beauty of ML/supervised learning – we don’t define any rules, the model simply learns itself!).

Another point to mention is that the initial weights in a kernel are randomised. The best thing about our approach (using transfer learning) is that we only need to change the final layer of our model (I will go through this in greater detail when we start looking at ResNet50). Since our model is pretrained on millions of images already, its kernels have weights that are far more suited to our X-ray images than if it was randomized.

When we introduce our testing set to our model, the model will look for these commonalities and particular features and will make a prediction!

The second step – Defining our functions

In order to train our model we need to create a few custom made functions. The first set of functions we shall define are an accuracy function, a training function, a validation function and a function that obtains the mean of our training and validation accuracy/loss.

Our accuracy function (given above) works in a very simple manner. It calculates the number of predictions that match the label (the true classification of the image) and then divides the sum by the total number of images passed to the model.

Let’s dissect our first function –

The training_step function applies our model to the images and creates an output (once again, visualise a hypothetical 5 x 5 2D image and try to figure out how the model proceeds). Self is simply a default object we have to include in our functions (refer to this link to understand it better – http://neopythonic.blogspot.com/2008/10/why-explicit-self-has-to-stay.html). It represents our model.

Okay, so what next? After our images are passed to the model we obtain two probabilities for our two classes (normal and Pneumonia). We select the highest probability and compare it to the label of the image. For example, let’s say our model predicted that the probability of an image (with pneumonia) being pneumonia was 0.3. To calculate our loss, we take the logarithm of the picked probability. If our probability is close to 1 (high) then its log value will be a very small negative number close to 0. If the probability is low (like in our case) then the log value will be a very large negative number. Multiply the two log values with -1 and we get a very large positive value (if our probability is close to zero, that is, it is a bad prediction).

Confused? Have a look at this graph –

The log of probability is on the Y axis. If this value is close to 0 (as in the case of a high probability), then our loss is a small positive value. If it is close to 1 (low probability) then our loss is a very high positive value.

I have specified my criterion to be F.cross_entropy but there are other loss functions you can use (CrossEntropyLoss is a commonly used loss function).

Validation_loss_a works similarly to our training_step. I’ll demonstrate it’s importance when describing the next set of functions. Our final function validation_epoch_end simply takes the average of our training loss, validation loss and accuracy and returns it.

This is our next set of functions to consider. All evaluate does is it takes a dataset (validation or testing depending on whether test =False/True). It obtains outputs by applying the model to the dataset and calculates loss. Notice that we have called model.eval() before we actually apply our model. This disables a few layers in our ResNet50 model and also turns off gradient calculation (explained in greater detail below).

get_lr is a simple function that obtains the learning rate from our optimizer’s parameters and returns it. Once again, I’ll explain the concept of learning rate (lr) below.

Now to the last bit. fit_one_cycle is the final, most powerful function that involves and uses all other functions we have defined earlier. It takes in eight arguments – number of epochs, maximum learning rate, model, training dataset (train_dl), validation dataset (val_dl), weight decay, gradient clip and the optimizer. Let’s go through fit_one_cycle line by line.

First of all, we’ve defined an optimizer, which is an algorithm by which we can reduce our loss to a minimum point. Our opt_func uses Stochastic Gradient Descent (SGD) as the optimizer.

Essentially, everything over here revolves around obtaining a gradient of our loss function. If you’ve read the code carefully you might have noticed loss.backward(). This function calculates the derivative of our loss function (dloss/dx) and then creates a gradient of this loss derivative. Our requirement is to achieve a minimum loss – we need to find the lowest point of the gradient.

An optimizer will iteratively tweak it’s parameters to reduce a function to its minimum. Gradient descent will move in the direction opposite to the steepest ascent by calculating the slope (which is dloss/dx) at every point (hence iteratively). Stochastic gradient descent is a more efficient and computationally friendly version of gradient descent.

What about learning rate? The size of steps taken by the optimizer to reach this minima is given by our learning rate. Too high a learning rate and we risk never reaching the minima.

There is a way we can prevent our lr from spiralling out of control and getting too high. We can use a one cycle learning rate scheduler to specify a maximum lr. During one whole training cycle, our lr will gradually increase, reach the max lr specified by us and then begin decreasing. You’ll also come across other schedulers (ReduceLRonplateau is a popular one) and you can use these in place of OneCycleLR and look at the results.

Weight decay is another variable I’ve introduced into the optimizer. Essentially, we don’t want our model to get too complex because that can lead to overfitting. We used data augmentation to prevent our model from overfitting on a data level. We introduce weight decay to prevent our model from overfitting on a model level.

The best way to ‘penalize’ complexity would be to add our weights to the loss function, but that isn’t very practical since our weights contain both positive and negative values. We could add the square of our weights to our loss function, but that would make our loss huge. We thus multiply our squares with a fixed weight decay to reduce their size. We reduce the value of these squares by a fixed amount (usually 0.1).

Even though I’ve displayed SGD as my optimizer over here, I will eventually change it to ‘Adam’ , another very popular optimizer. To understand more about that optimizer, take a look at this link- https://medium.com/mlearning-ai/optimizers-in-deep-learning-7bf81fed78a0. I got the above images from the same site.

Moving on, we use a for function to create a loop where a training phase and a validation phase is executed for each epoch (or cycle). Just like in model.eval(), we call model.train() to activate certain layers of our ResNet50 network.

We then create a second loop inside the first loop. Our training dataset is split into batches (one batch containing 64 images). We wrap train_dl in tqdm, which is a neat function that displays a progress bar for each epoch. For each image in a batch, we calculate the loss, obtain a gradient (loss.backward()), update our optimizer’s parameters by calling optimizer.step() and set our gradients to zero for the next batch.

You might have noticed a grad_clip function in the mix as well. Simply put, training gradients can be unstable depending on the learning rate and type of loss function. Erratic and large changes to our parameters (weights) can lead to a numerical outflow known as ‘exploding gradients’. To prevent gradients from assuming very large values or exploding out of our preferred range, we introduce an upper limit above which a gradient will be clipped. Check out this link- https://machinelearningmastery.com/how-to-avoid-exploding-gradients-in-neural-networks-with-gradient-clipping/ if you’d like to learn more about this concept.

To end our training phase, we call sheduler.step() to update our learning rate.

Our validation phase is very simple. We simply use the evaluate function to apply our trained model to our validation set and obtain our validation accuracy and loss. These results help us understand how our model is performing against new data during the training period.

The third step – Making our model

I’m using transfer learning in this project, which means that I don’t have to actually create my model by writing code. Nevertheless, it’s always useful to know about the various layers in a Convolutional Neural Network (CNN).

ResNet50 is a very commonly used model for image detection. It’s trained on the ImageNet dataset, which has over a million training images and around fifty thousand validation images. It has fifty layers (hence ResNet50) and it’s architecture looks something like this-

We start with our first convolutional layer containing 64 kernels of size 7 x 7 with a stride of 2 (think of ‘stride’ as the size of our footsteps – it determines the gap a kernel leaves when moving horizontally and vertically). We add a padding of 3 (we ‘pad’ the input image by adding extra pixels with a value of 0 to its length and height). Our input (from the ImageNet dataset) is an image of size 224 x 224, 3 colour channels (remember, ResNet50 is trained on coloured images).

Our output is normalized and is passed through a Rectified linear unit activation function (ReLU) to introduce non-linearity into our model. ReLU replaces all negative values in our tensor with 0, thus introducing a non-linear relationship between our outputs and inputs.

Our first convolutional layer, our batch normalization layer and our ReLU function make up our first block. Our second layer is a simple MaxPool layer which has a kernel of size 3 x 3 and a stride of 2. Maximum pooling layers will consider the area a kernel occupies, take the maximum value in that kernel and create a new feature map. This reduces the size of our image – indeed, our new output feature map is of size 112 x 112 with 64 channels.

Our next convolutional block has nine layers. The first layer has 64 kernels of size 1 x 1, the second layer has 64 kernels of size 3 x 3 and the third layer has 256 kernels of size 1 x 1. A batch normalization layer and a ReLU function follows every layer. We pass our output through a batch normalization layer.

‘ResNet’ means residual network. The idea is that we add our input back to our output and make our model learn about the difference between our output and input. If we were using a traditional neural network, our model would try to learn H(x), that is, the output. However, if we were to denote the difference between output and input (x) as R(x) –

R(x) = Output — Input = H(x) — x

We can rearrange this to obtain –

H(x) = R(x) + x

By adding x (our input) back to our residue (R(x)) our model can avoid something known as ‘vanishing gradients’. This site does an excellent job illustrating the concept- https://towardsdatascience.com/residual-blocks-building-blocks-of-resnet-fd90ca15d6ec

How does this link back to our convolutional block? After we’ve obtained a feature map from our inputs, we add our inputs back to this output feature map (we need to pass our input through one layer with 256 kernels of size 1 x 1 first to bring it to the same size as our output). The forms a ‘skip connection’ that skips over our three layers to reach our output.

The three layers in this block are repeated three times, giving us a total of nine layers in this convolutional block. Our new feature map has a size of 56 x 56 and 256 channels

Our third convolutional block has 12 layers. Our first layer has 128 kernels of size 1 x 1, our second layer has 128 kernels of size 3 x 3 and our last layer has 512 kernels of size 1 x 1. Again, we add our input back to our output to obtain a residual block. These three layers are repeated four times. Our new feature map has a size of 28 x 28 and 512 channels.

The fourth convolutional block (another residual block) has 18 layers. The first layer has 256 kernels of size 1 x 1, the second layer has 256 kernels of size 3 x 3 and our third layer has 1024 kernels of size 1 x 1. This is repeated six times and our resulting feature map is of size 14 x 14 and 1024 channels.

Our last convolutional block (you guessed it, another residual block) has 9 layers. It’s first layer has 512 kernels of size 1 x 1, the second layer has 512 kernels of size 3 x 3 and the third layer has 2048 kernels of size 1 x 1. This is repeated thrice and our resulting feature map has a size of 7 x 7 and 2048 channels.

We have one average pooling layer (which works similar to the max pooling layer, only that the kernel will take the average value of all elements within it) which reduces the size of our feature map from 7 x 7 to 1 x 1. We also flatten our feature map to get a output of size 1 x 2048.

Our final (and in practice the most significant layer) is a fully connected layer attached to a softmax function. This layer will reduce the number of channels to the number of output features (labels) we require. The original ResNet50 model has a fully connected layer with a thousand nodes, but we only want a result which has two values (probabilities for label pneumonia (1) or label normal (0)). To achieve just two nodes, we replace our last layer with our own custom built fully connected layer –

I’ve mentioned a ‘softmax’ function as well. This is a very crucial function that converts our results into a probability. We need our results to lie between 0 to 1 and add up to one. Softmax replaces every value (y) in output by e^y and then divides this by the sum of values to ensure that this adds up to one.

Okay, so we’ve finally made our model. All layers except the last fully connected one are untrainable – we cannot change the parameters (weights and biases) of those layers. Our training mainly affects the last layer. My explanation might have been confusing, so if you’d like some more clarity check out this YouTube video I found to be very helpful- https://www.youtube.com/watch?v=mGMpHyiN5lk

The fourth step – training our model

This is the fun part – we get to see our model perform on training and validation data and utilise all that we’ve coded.

We begin by evaluating our model’s performance against the validation dataset-

Since we haven’t actually trained our model, the validation accuracy is quite bad. Statistically, if we just randomly guessed we would be able to reach an accuracy of 50%. Let’s train our model and look at the improvements.

Before we begin, have a look at our fit_one_cycle function. It requires the number of epochs, a max learning rate, a gradient clip value, a weight decay value and an optimizer.

Wrapping our data with tqdm gives us some other pieces of information and lets us track our progress in each epoch-

That’s how our training looks. We can see that by epoch 14 (remember, our first epoch is designated epoch [0], so I am referencing number [13]) our training loss, validation accuracy and validation loss has stabilised.

Refer back to the fit_one_cycle function. I had created empty lists for training loss, validation accuracy and validation loss so that each value would get stored into their respective lists. These values can be used to plot line graphs illustrating the performance of our model over time.

The fifth step – testing our model

Let’s look at how our trained model performs against our test set-

Not bad! We’ve obtained an accuracy of 93.4% We could potentially improve this by altering the number of epochs, batch size, max lr, weight decay, gradient clip or optimizer.

Let’s have a look at the confusion matrix for this test set –

I’ve always found a confusion matrix to be the best way to visualize a model’s performance (in real terms). Here’s the code if you’d like to make your own confusion matrix-

Let’s look at our model’s predictions for various images-

Let’s look at an image our model couldn’t predict correctly-

This image (17th in our testing set) is fairly distorted and isn’t very clear. It’s understandable that our model couldn’t predict the right label.

Let’s also have a look at line charts displaying our model’s performance-

This graph above shows the variation of training loss over epochs. We can see a general downward trend- our model gets better at predicting images and thus the total loss decreases. By our 14th epoch the loss has stabilised.

This graph above displays our validation accuracy over epochs. Our validation accuracy was a bit erratic in the beginning but stabilised around epoch 14. It does, however, have an overall trend upwards.

This graph displays our validation loss. The general trend is downward, but it is fairly erratic in the beginning.

GPUs vs CPUs

GPUs make your life much easier – when training on CPUs each epoch took around six minutes to train. Twenty epochs would take at least two hours to complete. With a GPU, twenty epochs are completed in just over six minutes.

A great thing about Colab is that it gives you access to Google’s own GPUs. However, this access is quite limited and getting access to GPUs usually depends on luck. If you have a computer with a GPU, you can use that (if you want to use Colab, change your runtime type to GPU). You’ll also need to write some code to utilize your GPU-

We’ve defined a to_device function that will move data or models to our GPU. This is very important- if your data is in the GPU but your model is still in the CPU you will get an error. For example, we need to move our model to our GPU by simply writing –

My reflections on this project

There were many things I learned while doing this project. It gave me an opportunity to think about what I want to achieve from coding and think about how ML could change medicine.

First of all, I learned that attention to detail is particularly important – unfortunately, I learned this the hard way. For nearly two weeks my code returned the same testing accuracy of 62.5%. I tried and tried to solve this but couldn’t figure out why my training and validation set had 97% accuracy but testing remained that low. I realised my mistake when I looked at the mean and std values I had used to transform my testing dataset. Turns out I had used a wildly incorrect set of std values for the test data, resulting in the complete corruption of all images in that set. If I had paid attention to detail and checked my code line by line, I would’ve spotted this discrepancy ages ago!

Another thing I learned was about getting help. I discovered the go-to forums and platforms where you can ask your questions. Stackoverflow, Python discord and Jovian helped me whenever I couldn’t proceed. Talking to people who are familiar with code/Python also helps.

Finally, I now appreciate the importance of understanding concepts and underlying algorithms. Just knowing how to write code isn’t enough – one must have a keen understanding of how various algorithms and functions work. You must be able to visualise the whole process. Reading articles related to these concepts is a must.

ML in medicine is a new area for me, and even though my knowledge is limited, I have done some reading in the subject and would like to now give my perspective on how ML might have an impact on healthcare.

My understanding is that ML will become a part of the consultation of the future. It won’t replace healthcare professionals (or at least I hope it doesn’t!) but it will assist in the decision making process. For example, a program might make a parallel diagnosis and alert the doctor if their diagnosis and the program’s diagnosis doesn’t match. We might also see ML assisted healthcare being deployed in areas of the world that don’t have access to proper medical services. The applications are endless.

Of course, making diagnosis is a very complex affair. Doctors consider many aspects of a patient’s history to reach a decision. They tend to notice other things (a change in the patient’s walking style, demeanor, etc) that a program simply can’t do. However, technology moves at a blisteringly rapid pace. We may not have the ability to definitively diagnose patients using ML now, but that milestone will almost certainly be reached in the not-so-distant future.

This also brings me to another point I want to mention – doctors and healthcare professionals alike must also change and adapt to the presence of ML in the healthcare environment. They must also make an active effort to understand the software and take part in the design stages of these programs. It is imperative that doctors shed the idea that all they are meant to do is diagnose and treat. I do not mean to say that doctors must start learning how to code. However, they must be able to grasp the basic ideas and concepts that power a program and must get involved in the software production stage. As opposed to simply being advisors to a team of software engineers, doctors must be the people who define what a program should achieve and demand features and improvements (this approach would ensure that doctors remain in control – ensuring that the patients best interests are always of paramount importance).

Moving on, drug discovery is another area of healthcare that might see paradigm changes through ML. Bioinformatics and Cheminformatics are perhaps not as ‘chic’ as autonomous surgical robots or disease prediction programs, but their potential can in no way be understated. Today it takes researchers many years to find the correct mix of molecules that could make an effective (but not toxic) drug. Bioinformatics and Cheminformatics might actually make this process quicker and cheaper (I did a short course of Bioinformatics as well – I found it very interesting!).

We tend to see supervised learning as the dominant ML subcategory in healthcare. This makes sense- it’s probably better to use a data driven approach since that doesn’t require experimentation or major assumptions on the model’s part. Reinforcement learning (RL) hasn’t made many inroads in healthcare in part due to this- it would be very irresponsible to use Temporal Difference learning to bootstrap and make assumptions regarding future results of a certain treatment.

However, I do think that we’ll slowly see RL making inroads in medicine as well. I envision it being used primarily in drug discovery. We could define a goal of creating a compound with low toxicity and high effectiveness. Any step taken (for example, the addition of a particular molecule) that contributes to the compound’s efficacy would result in the model getting a reward. It will thus attempt to find those combinations that maximize its rewards (if you are really curious about RL have a look at this course by UCL Professor David Silver – link).

What next for me?

I’m really happy with this project, but I do understand that in the spectrum of complexity, it is on the less difficult side. My plan for the future is to learn Python and do projects in tandem, while gradually increasing the complexity of each project. I’m currently doing a course on Liver segmentation using Monai, which is a library specifically for medical imaging. I’ve also created a playlist of all useful courses and videos I seen on Python (I would suggest this for everyone who’s staring with coding) since it allows me to keep track of what I’ve done and what I plan to do next.

This has been a very long blogpost, I think it’s a good idea to end it here. I hope it’s been a good read and has motivated you to learn Python and do a project of your own!