This book will give you a practical introduction to Python programming. Python is a big language, so it’s not our intention to cover everything there is to know. We'll help you build solid foundations, orient you in the universe of Python, and put you in a position to direct your own learning.

The Python Apprentice

Preface

In this chapter we’ll cover obtaining and installing Python on your system for Windows, Ubuntu Linux, and macOS. We’ll also write our first basic Python code and become a acquainted with the essentials Python programming culture, such as the Zen of Python, while never forgetting the comical origins of the name of the language.

Getting started

Python includes a rich selection of built-in collection types which are often completely sufficient for even quite intricate programs without resorting to defining our own data structures. We’ll give an overview of some of these fundamental collection types now – enough to allow us to write some interesting code – although we’ll be revisiting each of these collection types, together with a few additional ones, in later chapters.

Strings and collections

Modularity is an important property for anything but trivial software systems as it gives us the power to make self-contained, reusable pieces which can be combined in new ways to solve different problems. In Python, as with most programming languages, the most fine-grained modularization facility is the definition of reusable functions. But Python also gives us several other powerful modularization mechanisms.

Modularity

One of the most fundamental design elements of the Python language is its use of objects . Objects are the central data structure not only of user-level constructs but also many of the inner workings of the language itself. In this chapter we’ll start to to develop a sense of what this means, both in principle and in practice, and hopefully you’ll start to appreciate just how pervasive objects are throughout Python.

Built-in types and the object model

Chapter 5 – Exploring built in collection types

Exploring built in collection types

Exception handling is a mechanism for halting “normal” program flow and continuing at some surrounding context or code block.

Exceptions

The abstract notion of a sequence of objects is ubiquitous in programming. It can be used to model such widely different concepts as simple strings, lists of complex objects, and indefinitely long sensor output streams. It probably won’t surprise you to learn that Python includes some very powerful and elegant tools for working with sequences. In fact, Python’s support for creating and manipulating sequences is one of the highlights of the language for many people.

Comprehensions, iterables, and generators

You can get a long way in Python using the built in scalar and collections types. For many problems the built in types, together with those available in the Python Standard Library, are completely sufficient. Sometimes though, they aren’t quite what’s required, and the ability to create custom types is where classes come in.

Defining new types with classes

Reading and writing files is a key part of what many real-world programs do. The notion of a file , however, is somewhat abstract. In some cases a file might mean collection of bytes on a hard disk; in others cases it might mean, for example, an HTTP resource on a remote system. These two entities share some behavior. For example, you can read a sequence of bytes from each. At the same time, they’re not identical. You can, for example, generally write bytes back to a local file while you can’t do that with HTTP resources.

Files and resource management

When we build programs of even minor complexity, there are countless ways for defects to creep into our code. This can happen when we initially write the code, but we’re just as likely to introduce defects when we make modifications to it. To help get a handle on defects and keep our code quality high, it’s often very useful to have a set of tests that you can run that will tell you if the code is acting as you expect.

Unit testing with the Python standard library

Even with a comprehensive automated test suite, we can still get into situations where we need a debugger to figure out what’s going on. Fortunately, Python includes a powerful debugger with the standard library: PDB. PDB is a command-line debugger, and if you’re familiar with tools like GDB then you’ll already have a good idea of how to use PDB.

Debugging with PDB

As we said at the beginning, Python is a big language. Our goal with this book is get you started in the right direction, to give you the foundation you need to not just program Python effectively but direct your own growth with the language. Hopefully we’ve done our job!

Afterword: Just the Beginning

A virtual environment is a light-weight, self-contained Python installation. The main motivation for virtual environments is to allow different projects to have control over the versions of installed Python packages, without interfering with other Python projects installed on the same host. A virtual environment consists of a directory containing a symbolic link to (Unix), or a copy of (Windows), an existing Python installation, together with an empty site-packages directory into which Python packages specific to this virtual environment can be installed. A second motivation for virtual environments is that users can create a virtual environment without needing administrator rights on their system, making it easy for them to install packages locally. A third motivation is that different virtual environments can be based on different versions of Python, making it easier to test code on say Python 3.4 and Python 3.5 on the same computer.

Appendix A &ndash; Virtual environments

Packaging and distributing your Python code can be a complex and sometimes confusing task, especially if your projects have lots of dependencies or involve components more exotic than straight Python code. However, for many cases it’s very straightforward to make your code accessible to others in a standard way, and we’ll see how to do that using the standard distutils module in this section. The main advantage of distutils is that it’s included in the Python Standard Library. For much beyond the simplest packaging requirements you’ll probably want to look at setuptools instead, which has capabilities beyond those of distutils , but which is correspondingly more confusing.

Appendix B &ndash; Packaging and distribution

Appendix C – Installing third-party packages

Appendix C &ndash; Installing third-party packages

Though more and more projects are starting to be “primarily Python 3” or even “Python 3 only”. We don’t cover regular expressions – also known as regexes – in this book. See the documentation for the Python Standard Library re module for more information. https://docs.python.org/3/library/re.html Technically modules don’t have to be simple source code files, but for the purposes of this book that is a sufficient definition. Technically some of these compiled languages do provide mechanisms for defining functions dynamically at runtime. However, these methods are by far the exception rather than the rule in almost all situations. Python code is actually compiled to byte-code, so in that sense Python has a compiler. But the compiler is doing substantially different kinds of work than what you might be used to from popular compiled, statically-typed languages. You’ll notice that here we’ve referred to the object reference with the name x as x . This is admittedly a bit sloppy since, of course, x will generally mean the object referred to by the object reference with the name x . But that’s a mouthful and a bit overly pedantic. Generally speaking, the context of the use of reference names will be sufficient to tell you whether we mean the object or the reference. Garbage collection is an advanced topic that we won’t cover in this book. In short, though, it’s the system by which Python deallocates and reclaims resources (i.e. objects) which it determines are no longer in use. Since assigning a list reference to another name doesn’t copy the list, you may be wondering how you could make copy if you wanted. This requires other techniques which we’ll look at later when we cover lists in more detail. Note, however, that Python does not enforce this behavior. It is entirely possible to create an object which reports that it is not value-identical to itself. We’ll look at how to do this — should you for some reason feel the urge — in later chapters. Though there’s no universally accepted terminology, you’ll often see the term parameters or formal parameters used to mean the names declared at the function definition. Likewise, the term arguments is often used to mean the actual objects passed into a function (and, thus, bound to the parameters). We’ll use this terminology as needed throughout this book. And this behavior is part of the syntax implementation, not the type system. Back in Python 2 days range() was a function which returned a list. The Python 3 version of range is much more efficient, useful and powerful. This, of course, brings to mind the classic joke: The two hardest problems in programming are naming, cache coherence, and off-by-one errors. Arguably, it’s poor design to have a module containing functions of the same name, because of this issue. We cover the iterable protocol in detail later in this chapter. Well, they can, but recall that iterating over a dictionary yields only the keys! We often just use the term generator to refer to generator functions, though sometimes it may be necessary to distinguish generator functions from generator expressions , which we cover later. The authors are sworn by sacred oath never to use either Fibonacci or Quicksort implementations in demonstrations or exercises. This has nothing whatsoever to do with the order in which you should watch the episodes of Star Wars. If that’s what you’re looking for, might we suggest Machete Order . In fact, it is possible to change the class of an object at runtime, although this is an advanced topic, and the technique is only rarely used. It’s generally unhelpful to think about the destruction of objects in Python. Better to think of objects becoming unreachable. The formal arguments of a function are the arguments listed in the function definition . The actual arguments of a function are the arguments listed in a function call . Nor any language, for that matter. You can get the full details of the with-statements syntactic equivalence in PEP 343 . You can learn all about the BMP format here . Like, for example, sequence protocol is for tuple-like-objects. E asier to A sk F orgiveness Than P ermission↩ Test-driven development, or TDD, is a form of software development where tests are written first, i.e. before you write the actual functionality to be tested. This may seem backwards at first, but it can be a surprisingly powerful technique. You can learn more about TDD here . Note that we don’t actually try to test any functionality yet. This is just the initial skeleton of our test suite that lets us verify that the test method executes. A tenet of TDD is that your tests should fail before they pass, and you should only ever write enough implementation code to make you tests pass. In this way, your tests stand as a complete description how your code should behave. You may have noticed that the setUp() and tearDown() method names aren’t in line with what PEP 8 prescribes. This is because the unittest module predates those parts of PEP 8 which specify the convention of function names being in lower case with underscores. There are several such cases in the Python standard library but most new Python code follows the PEP 8 style. If we were strictly interpreting TDD here, this amount of implementation would have been too much. To make our existing test pass, we didn’t need to actually implement line counting; we just needed to return the value 4. Subsequent tests would have then forced us to continually “update” our implementation as they described a more complete version of the analysis algorithm. We think you’ll agree that such a dogmatic approach would be inappropriate here and, frankly, in real development as well. Notice that we can use print with or without parentheses. Don’t be alarmsed – we haven’t regressed to Python 2. In this context print is a PDB command rather than a Python 3 function . 

Community Questions