If your blog post contains more than a few code snippets you will probably want to distribute it as a separate file or files in addition to the in-post listings. Your readers can then compile and/or run the code without having to laboriously copy and paste it from their browser.
The method of distributing source code I will cover here is as a ZIP file downloadable directly from your site. Another method is by creating a Github repository which I will cover in a separate post.
Using ZIP files is the simplest method as you just need to copy all the necessary files into a single ZIP, upload it to your site and provide a link within your post. Readers can then just click the link, select the Download option and unzip the files to the location of their choice.
So what should your ZIP file contain? Basically everything your readers will need to get your source code running. This could be just a single file such as a .py file which can be run by the Python interpreter, or it could be a number of files including secondary resources such as makefiles, images, CSS, or even sample data in CSV, JSON or XML files.
If your source code consists of just a single file you might decide you want upload that rather than bothering to zip it and give your readers the bother of having to unzip it. However, if you are using a content management system (which you almost certainly would be) it is likely to block certain types of file. For example if you try to upload a file with a .c extension in a WordPress site via "Upload New Media" you will be rebuffed with a "Sorry, this file type is not permitted for security reasons".
This is a bit irritating and is likely to leave you thinking "this is my site, I should be able to upload what I want". If you have unmanaged hosting which basically gives you your own (possibly virtual) server then you will have direct access to its file system so can then bypass WordPress to upload files directly. However, backdoor cheats are not advisable even if they are entirely benign and well-meaning so just stick with a ZIP file.
There is still the issue of how and where to provide a link to the ZIP file. When I started my first programming blog I had a separate page containing all the links with a note in each post saying something like "click on the Downloads page to download the source code". I quickly realised this was inconvenient for users: they would have to leave the current page, search a rapidly growing list of links on another page for the one they want, and then find their way back to the right position on the original page. Very irritating!
I therefore adopted the convention of embedding the links in their corresponding posts. Each of my post has a pair of links, one for the ZIP file and another for the Github repository, contained in their own section with a separate subheading so that anyone scrolling up or down searching for the links will be able to spot them easily. I try to place them at a point where readers are going to start getting interested in grabbing the source code for themselves. The convenience of your readers always comes first.