Code examples in this book are shown in a lucida console text:

>>> def square(x):
...     return x * x
...

Some of our examples show code saved in files, and others — such as the one above — are from interactive Python sessions. In such interactive cases, we include the prompts from the Python session such as the triple-arrow >>> and triple-dot ... prompts. You don't need to type these arrows or dots. Similarly, for operating system shell-commands we will use a dollar prompt $ for Linux, macOS and other Unixes, or where the particular operating system is unimportant for the task at hand:

$ python3 words.py

In this case, you don't need to type the $ character.

For Windows-specific commands we will use a leading greater-than prompt:

> python words.py

Again, there's no need to type the > character. For code blocks which need to be placed in a file, rather than entered interactively, we show code without any leading prompts:

def write_sequence(filename, num):
    """Write Recaman's sequence to a text file."""
    with open(filename, mode='wt', encoding='utf-8') as f:
        f.writelines("{0}
".format(r)
            for r in islice(sequence(), num + 1))

We've worked hard to make sure that our lines of code are short enough so that each single logical line of code corresponds to a single physical line of code in your book. However, the vagaries of publishing e-books to different devices and the very genuine need for occasional long lines of code mean we can't guarantee that lines don't wrap. What we can guarantee, however, is that where a line does wrap, the publisher has inserted a backslash character in the final column. You need to use your judgement to determine whether this character is legitimate part of the code or has been added by the e-book platform.

>>> print("This is a single line of code which is very long. Too long, in fact, to fit on a single physical line of code in the book.")

If you see a backslash at the end of the line within the above quoted string, it is not part of the code, and should not be entered.

Occasionally, we'll number lines of code so we can refer to them easily from the narrative next. These line numbers should not be entered as part of the code. Numbered code blocks look like this:

def write_grayscale(filename, pixels):
    height = len(pixels)
    width = len(pixels[0])

    with open(filename, 'wb') as bmp:
        # BMP Header
        bmp.write(b'BM')

        # The next four bytes hold the filesize as a 32-bit
        # little-endian integer. Zero placeholder for now.
        size_bookmark = bmp.tell()
        bmp.write(b'x00x00x00x00')

Sometimes we need to present code snippets which are incomplete. Usually this is for brevity where we are adding code to an existing block, and where we want to be clear about the block structure without repeating all existing contents of the block. In such cases we use a Python comment containing three dots # ... to indicate the elided code:

class Flight:

    # ...

    def make_boarding_cards(self, card_printer):
        for passenger, seat in sorted(self._passenger_seats()):
            card_printer(passenger, seat, self.number(),     
                self.aircraft_model())

Here it is implied that some other code already exists within the Flight class block before the make_boarding_cards() function.

Finally, within the text of the book, when we are referring to an identifier which is also a function we will use the identifier with empty parentheses, just as we did with make_boarding_cards() in the preceding paragraph.