Throughout this book, we have very stubbornly resisted writing code in the most correct Python Way. “That’s not how a Python programmer would do it,” was a familiar refrain heard from the Head First Programming technical reviewers. Without fail, and with the greatest of respect to our reviewers, we generally ignored this advice.

You see, every programming language has its preferred, tried and true, agreed, and accepted way of doing certain things, collectively known as programming idioms. And Python is no exception. This is, of course, a very good thing, because the more programmers using a particular language who follow the standard way of doing something, the better. Except, that is, when writing a book like this: one designed from the get-go to teach programming concepts.

There are times when the idiom, although very smart, can be hard to understand and even harder to explain. So, when we had a choice between showing you how to do something in a generic way over showing you how to do it the Python way, we nearly always chose the former approach over the latter. This has the effect of making some of the code in this book positively repulsive to hardened Python programmers, something that is of little concern to us, as this book isn’t for them (and they have lots of other books already).

This book is for you: the reader who wants to learn how to program regardless of the programming language chosen.

Having said all that, if you now want to learn more about The Python Way, start by scanning through the booklist and book reviews maintained on the main Python website:

If you remember way back in the Readme, we stated we were using release 3 of Python in this book. Of course, there’s much more to Python that just release 3, as the previous version of the language, release 2, is still very, very popular.

And rightly so. Python 2 has been around for nearly a decade and has an impressive collection of technologies built around it, including Google’s App Engine, the Django Web Framework, Zope’s Content Management System, and the Twisted Networking Libraries (to name just a few).

Despite all the Python 2 goodness out there, we still went with release 3 for this book and our reasoning was very simple: better to go with the future than settle on the past. The good folks that bring the world Python have stated that Python 3 is where all the cool, new stuff will happen with the language. Release 2 has entered what’s known as bug-fix mode only: if something is found in 2 that is broken, it’ll be fixed, but no new features will be added.

And here’s the good news: there’s not much difference between the code you’ve been writing for Python 3 and what you would write for release 2, should you find yourself in the position of needing to (perhaps as a result of needing to fix some existing Python 2 code or working with a technology that’s based on Python 2).

Here are a few lines of Python 2 code that highlight some of the differences:

When it comes to teaching programming concepts, there’s more than enough to cover without trying to cover multiple programming languages.

We like Python and hope over the course of this book that you’ve grown to like Python, too. However, if you want to explore or need to learn another programming language, there’s lots of help out there. Simply going to your favorite search engine and typing in the name of your chosen programming language produces a torrent of sites offering to provide you with everything you need to know.

Two modern languages that are important are Java and C#. And guess what? If you have to learn these technologies, Head First Labs has you covered.

Having completed this book, you can now pick up either of these books and confidently work your way through them.

Of course, if you find yourself working in a Java or C# programming environment and missing Python, don’t despair. Two active projects within the Python Community integrate Python with the above programming languages and are well worth checking out (search on the project name to learn more):

And, no, before you ask, this has nothing to do with program-testing robots automatically testing your code for you (which, we agree, would be nice).

Automated testing does have everything to do with trying to make sure, as far as possible, that your code is working properly.

But, how is this possible?

The truth is, it’s very hard to know for sure that your code is working perfectly 100% of the time. Programs and software systems are complex beasts. Over time, they grow, and it gets increasingly hard to know for sure if they are working quite the way you want them to.

To help, programmers test their code. When they are done, they test, test, then test some more. And just to be sure, they test again. In fact, programmers often test to destruction, which refers to attempting everything they know to try and break the program and make it misbehave. If testing finds a problem, the code is then fixed so that whatever it was isn’t a problem anymore.

To help with the grunt work that testing sometimes is, Python comes with a handy built-in module called unittest. This module’s sole purpose in life is to allow you to write code that tests your code. Trust us, this isn’t as strange as it sounds. The unittest module provides a framework within which you can exercise your code to ensure it’s working the way you want it to.

The idea is simple enough: as you write your code, you write a little extra bit of code based on unittest to check that your new code is working properly. If the test works (that is, it successfully demonstrates that your code is OK), you are then in a position to automate the testing of your code by reusing your unittest code.

For more details, check out the description of unittest in your favorite Python book or online in the official Python documentation.

And now that you know about unittest, you have no excuse not to use it to test your code.

This is not as disgusting as it sounds.

Debugging is related to testing. It is the process of dealing with errors that aren’t picked up during testing but, instead, blow up in your face when you run your code or—worse—blow up in the face of your user!

Tracking down where a problem is can sometimes feel like a bit of an art form, but there are some tried and true techniques that can make things easier for you. Experience helps a lot.

One of the most important things you can know about when it comes to debugging code is a thing called the debugger. This is a software tool that can be used by programmers to run code step by step or line by line. As the program runs, the debugger lets you watch what’s going on and then potentially see when something goes wrong. If you can work out where in your code the problem lies, it makes it easier to fix, and the debugger is designed to help you do just that.

It is a rare programming technology indeed that comes without a debugger. Python’s is called pdb and it can be accessed from within IDLE and within the Python Shell. Check the Python online documentation for more information on pdb.

As mentioned at the top of the page: debugging is related to testing. Typically, you debug your code after it is up and running and (possibly) delivered to your user. You test your code as you write it and before you give your program to your users. The idea is that you only ever give a user your program when you’re happy it works the way you want it to.

To be honest, though, there are no hard and fast rules here, and a lot of programmers blur the line between debugging and testing, treating it all as one activity.

Throughout the 10½ chapters of this book, you’ve consistently executed your code from within the IDLE programming environment. This has been great while developing and working on your code, but it’s probably not how you want your users to run your programs. It turns out there’s more than one way to do it when it comes to running your code. The method available to you (and your users) will vary depending on the operating system you’re using.

Your operating system might have a file association already in place that allows you to double-click on a Python program and have it execute for you. If this is the case, feel free to double-click to your heart’s content. If not, here’s how to start Python from the command line on the “big 3” operating systems. Let’s assume the program you’re running is called coffee_pos.py:

Chapter 11 introduced the important concept of classes, and throughout the book we’ve touched on objects in lots of different places. Doing justice to all the concepts of object oriented programming (OOP) would easily take an entire book all on its own.

The bit of OOP covered in Chapter 11 relates to the concept of encapsulation. This is the process of bundling data with methods into prebuilt templates that can be used to create functionally identical objects of a certain type.

Now... if your eyes glazed over reading that last line, don’t worry; you are as normal as the rest of us. OOP is full of terminology like this. As well as encapsulation, there’s inheritance and polymorphism, too.

Discussing all the ins and outs of OOP is something that takes a little time and it is not something that we are going to try and do on just one page!

That said, OOP really comes into its own when your programs get very large and turn into software systems. When systems start to scale (get really, really big), the importance of proper design takes center stage, and OOP can help here—big time. Again, there’s help from those lovely people at Head First Labs.

There are plenty of great books that believe it’s impossible to learn about programming without also learning about algorithms.

The word “algorithm” is used to describe a precise and established way of solving a particular problem in any programming language. It’s often useful to think of an algorithm as a recipe.

In the good ol’ days, it was certainly true that every programmer had to have a good grasp of algorithms in order to get anything of any worth done. But, luckily for you, this is no longer the case.

Nowadays, with programming technologies such as Python (and Ruby, Perl, Java, and C#), this is less of an issue because modern programming languages just do so much for you.

For instance, if you need to sort something in Python, you either call the sort() method on a object or use the built-in sorted() function, and the thing you are working with is duly sorted. You are probably less concerned (and rightly so) with how the sort actually occurred—that is, with the details of the algorithm used to sort your data. Was it the quicksort algorithm or the bubblesort? Maybe it was timsort or something else entirely? Maybe you don’t care, because calling sort() or using sorted() orders your data in the way you desire and frees you to move onto some other problem that needs solving.

You could take the time to write a really cool sort function and learn lots about algorithms in the process but, let’s face it, life is far too short.

If you want to write your own programming language, you’ll need to learn lots about algorithms. If all you want to do is use an existing programming language (like Python), you can worry less about algorithms and more about writing code, which is precisely how it should be (in our opinion).

There are a bunch of advanced programming topics that were never likely to make it into a book like this. Here is a list of six such topics (all supported by Python 3).

Threads are a programming technology that allows you to break your program into discrete coded chunks that can then be executed in parallel or concurrently. Each chunk is known as a thread. Using threads can result in some beautiful coding designs, which can make the solving of a certain class of problem almost trivial. Under certain circumstances and restrictions, it is possible to have threads communicate with each other and share data, which, although possible, is hard to get right and can lead to some rather tricky and hard-to-track-down bugs. If you think you need threads, approach with extreme caution and be prepared to have your brain expanded in ways that you never thought possible.

Recursion is a programming technique that allows you to create a function that is capable of calling itself in order to get its work done. There are certain types of mathematical problems that are well-suited to a recursive solution, but not much else.

Metaprogramming refers to writing programs that can write other programs or manipulate themselves (sounds icky, and it can be). It is not for the faint of heart.

Functional programming (typified by languages such as Lisp) is a technique that treats computation as a series of function calls that specify what is required of the program, as opposed to a procedural program, which details the steps that are required in order to solve a problem.

Regular expressions are a technology that allows you to specify concisely what it is you are looking for in your data. Having written a regular expression (or regex), Python can then go and get it for you. Every programmer should know how to take advantage of regexes. The trouble is, they look so very strange at first that most coders recoil in disgust. This is a pity, as we think regexes are super cool and well-worth learning.

Unicode is an industry standard that allows you to consistently represent and work with text written in most of the world’s languages or “writing systems.” If you are working with text originating from somewhere other than the place where they speak your language, then you’ll want to know a bit about the Unicode character encoding system.

If you find yourself needing any of this stuff, best to start on the Internet and do some background reading on the topic before buying a book with your hard-earned cash. The Wikipedia entries for each of these six topics are good starting points.

It might be hard for you to fathom, but there is life beyond IDLE. There’s life beyond the Python Shell, too. Both IDLE and the Python Shell are great learning tools, but sooner or later, you might find yourself wanting more.

iPython is a bit like the Python Shell on steroids, and a lot of Python programmers swear by it. It has a lot of extra features over and above those in the normal shell that are designed to make the Python programmer’s life easier. It is well-worth looking into.

When it comes to full-blown programming environments, there are many choices. Search the Internet for “Python IDE” to see a complete list. A few that come up more than most include: Komodo, Eclipse, and Eric. It’s worth taking a look at each, and then deciding if one of them (or something else entirely) is just right for you.

IDLE and the Python Shell may satisfy your needs. But, if you are looking for more from your programming tool, there’s lots of choices out there.

As for text editors... well, there are lots of choices, too. Some people prefer Emacs, while others prefer vi. The Head First Labs advice is to try out a few editors before picking the one that best suits your needs.