We closed the previous lesson with EasyTask calculating remaining days, progress percentages and urgencies, but with two very visible shortcomings: the card was printed at a rate of one line per item, illegible, and all the data was still written inside the code. To register the task of another client you had to open the editor.

This lesson fixes both things, and with that your program crosses an important frontier: it stops being something that gets edited and becomes something that gets used. A program that gets used has two points of contact with the world: the input (the data it receives) and the output (the results it displays). In Python those two points are called input() and print().

You have known print() since module 1, but only in its simplest form. Here you will see it in depth: several arguments, the sep and end parameters, escape characters, and above all f-strings, the tool with which text is composed in modern Python and with which you will at last be able to mix words and variables on a single line, line up columns and display decimals to whatever precision you want. Then input() will arrive, and with it a detail that conditions everything that follows: input() always returns text, even when the user types a number.

1. Input and output: a program's two points of contact
2. print() with several arguments
3. The sep and end parameters
4. Escape characters: \n, \t and quotes
5. f-strings: interpolating variables
6. Expressions inside an f-string
7. Format specifiers: decimals and alignment
8. Other ways of formatting that you will see in other people's code
9. input(): asking for data from the keyboard
10. The crucial point: input() always returns text
11. EasyTask: the card is asked for and presented
12. Common mistakes and tips
13. Exercises
14. Conclusion

Any program, from the simplest one to a banking system, follows the same three-stage scheme:

Until now you have worked in the middle: variables (02-01) and expressions (02-02) are pure process. The input was fixed in the code and the output was rudimentary. We are going to cover both ends.

Data can come in by many routes — keyboard, files, network, sensors — and go out by just as many. In this course we start with the most direct: the keyboard to come in and the screen (specifically, the terminal) to go out. Reading and writing files arrives in Saving Data to Files.

A background warning worth bearing in mind from day one: everything that comes in from outside is suspect. The user may type a number where you expected a name, leave the field empty or write "HIGH" in upper case. Checking that the data is correct is called validating, and it is the subject of the next lesson. Here we deal with receiving it and displaying it.

So far you have used print() with a single value. But it accepts several, separated by commas:

Output:

This solves at a stroke the problem we left pending in the previous lesson: remember that "Title: " + title only worked with text, and that "Days: " + 3 gave a TypeError. With commas there is no problem, because print() converts each value to text automatically:

Numbers, booleans, None: print() displays them all without complaint.

There are two details to observe. First: a space appears between each argument, put there by Python, not by you. That is why "Title:" has no trailing space and the output still looks right. Second: there is no limit on the number of arguments.

Notice the result: the % appears separated from the number because the automatic space is put between all the arguments. That automatic space is convenient but also rigid; the next section explains how to control it.

And a print() with no arguments prints a blank line:

It is cleaner than print(""), which does the same thing.

print() accepts two named parameters that modify its behaviour.

sep changes the separator placed between the arguments. By default it is a space.

That last example is the typical use: composing a date or a path without repeating the separator by hand.

end changes what is printed at the end, after the last argument. By default it is a line break, "\n"; that is why every print() starts on a new line.

Output, all on a single line:

By putting end="" you are telling print() not to break the line, so the next statement carries on where the previous one left off. It is the mechanism behind progress bars and any output built up in parts.

Combining the two:

Named parameters like these are called keyword arguments, and they are studied in depth in Parameters and Return Values. For now it is enough to know that they are written name=value and that they go at the end of the call.

Inside a text string, the backslash \ has a special meaning: together with the character that follows it, it forms an escape sequence representing something that cannot be typed directly.

Line breaks. A single print can produce several lines:

Tabs. \t advances to the next tab stop, which gives a column effect:

It works, but with an important limitation: tab stops are fixed (normally every 8 characters), so if a name is longer than the stop, the column goes out of line. To align properly you use the width specifiers of f-strings, which you will see in section 7.

Quotes inside text. There are three ways of dealing with it:

The first and the third are the most readable; the second is useful when the text contains both types of quote.

Literal backslash. Since \ starts an escape, to write a backslash you have to double it:

There is also the raw string, which disables escapes: it is marked with an r in front. It is very handy for Windows paths:

And for long, multi-line text, triple quotes preserve the format exactly as you write it:

We come to the central tool of this lesson. An f-string (formatted string) is a string preceded by the letter f in which you can insert variables between curly braces {}.

Compare the three ways of doing the same thing:

The decisive advantage of the f-string is that the code looks like the result. You see the complete sentence and, inside it, in its exact place, the gap the data will fill. And it works with any type, with no conversions:

The f goes right up against the opening quote, and it can be used with single, double or triple quotes. If you forget the f, there is no error: the braces are printed literally, which is a very common slip.

If you need a literal brace inside an f-string, double it: {{ produces {.

Inside the braces there is room not only for variables: there is room for any expression of the ones you learned in the previous lesson.

Notice the last line: inside the braces there is a complete logical expression, and in the f-string single quotes have been used for 'high' because the double ones are already taken by the outer string. Mixing the two types of quote is the way to avoid the clash.

That said, a piece of style advice: the fact that you can put complex expressions in does not mean you should. This line is correct but illegible:

It is far better to calculate beforehand, with a name that explains what it is, and limit the f-string to displaying:

The practical rule: inside an f-string, short and obvious expressions; everything else, in a named variable.

A useful trick for debugging: if you put an = after the expression, the f-string also displays the code that produced it.

It is extremely handy when you are hunting for why a value is not what you expected.

Inside the braces you can add, after a colon, a format specifier controlling how the value is presented. The general syntax is {value:format}.

The problem is obvious as soon as you calculate a percentage:

.2f means "floating-point format with 2 decimals". It rounds, it does not truncate: 37.336 with .2f gives 37.34.

It is the specifier you will use most. Any quantity calculated with / that is going to be shown to a person should carry it.

This is where f-strings definitively beat the \t tab. You can set a minimum width and an alignment:

(The underscores stand for spaces.)

Let's see it composing a table of the Alba Studio team:

The text is aligned to the left (<) because that is how words are read; the numbers to the right (>) because that is how units, tens and hundreds line up. It is the convention of any well-made table.

And width and decimals can be combined, putting the width first and the precision afterwards:

Now we are talking: a perfect column, with two decimals in every case.

That last one deserves a note: {0.375:.1%} multiplies by 100 and adds the symbol. If your value is already on a 0-100 scale, use .1f and write the % yourself.

f-strings have existed since Python 3.6 and are the recommended form today. But you will find code — old tutorials, legacy projects — written with the two earlier forms, and it is worth recognising them.

The .format() method, from Python 3.0 onwards:

The {} gaps are filled in order with the arguments of .format(). The specifiers after the colon are the same as in f-strings, so what you learned in the previous section serves you just as well.

The % operator, inherited from the C language and still present in a lot of old code:

Here %s is a gap for text, %d for an integer and %.2f for a decimal with two figures. It is the most cryptic of the three and the most error-prone.

Take this away with you: write f-strings, and if you come across the other two, you now know what they do.

input() is the function that stops the program and waits for the user to type something and press Enter.

That program sits waiting without saying anything, which is a dreadful user experience. That is why input() accepts an argument: the prompt message, which is displayed before waiting.

A run (what the user types is where the cursor is, marked separately here):

How it works step by step:

Three points of use that make all the difference:

1. End the prompt with a space, or a colon and a space. Without it, what the user types will appear stuck to the message:

2. Say exactly what you expect. A vague prompt produces useless data:

3. The result has to be stored. Writing input("Name: ") without assigning it to anything asks for the data and throws it away. It is a common slip.

And a consequence you notice when running: input() blocks the program. Nothing else happens until the user presses Enter. If your program seems to have "hung", check whether it is waiting for input.

Here is the most important idea of the lesson, and it is worth reading twice:

input() ALWAYS returns a value of type str, without exception, even when the user types a number.

Check it:

The user has typed 3, on screen you see 3, but what is stored is the text "3", not the number 3. And that has immediate and disconcerting consequences:

"3" * 2 is string repetition, which you already saw in the previous lesson: it produces "33". It is not a flaw in Python; it is that you are multiplying text.

And if you attempt real arithmetic, the program stops:

It is the same TypeError from the previous lesson, seen now from the other side. Let's sum up what happens depending on what you attempt:

Notice the last row: displaying the data works perfectly. The problem only appears when you want to calculate with it.

That is why, in this lesson's application, EasyTask will ask only for data that is text by nature — title, assignee, priority — and will not ask for the estimated days or the hours. As soon as a number is needed, we will have to convert it, and that conversion, together with what happens if the user types "three" instead of "3", is exactly the content of Type Conversion and Validation.

So we leave two loose ends noted down:

• input() returns text and sometimes we need numbers.
• The user may write "HIGH", " high " or "urgent", and none of the three matches "high" (that discovery from the desk check in 01-05).

Both are tied up in the next lesson.

Version 0.4 of easytask.py. The program asks from the keyboard for the three text items of the task and displays a card lined up in columns with f-strings. The numeric data is still in the code, waiting until we know how to convert it.

A complete run, with Marta registering the job for client Vidal:

Let's go over the techniques used, because the example condenses the whole lesson:

• "=" * WIDTH draws the separators. It is the string repetition from the previous lesson, here with a very practical use.
• {text:^{WIDTH}} centres the title within the total width. Notice the advanced detail: the width is not written by hand, it is another variable between braces. So, by changing WIDTH on the first line, the whole card readjusts.
• {'Title':<16} reserves 16 characters for the label, aligned to the left.
• {title:>{WIDTH - 16}} takes up the rest of the line with the value aligned to the right. Inside the width braces there is an expression, WIDTH - 16, perfectly valid.
• {progress_percentage:>{WIDTH - 18}.1f} % combines width, alignment and one decimal; the - 18 instead of - 16 leaves room for the two characters of the % that follow, so the line still measures exactly WIDTH.
• str(completed) converts the boolean to text. It is necessary because the < and > alignment specifiers work differently with booleans than with strings; by converting it first, it lines up like any other text. The str() function is, precisely, the first thing you will see in the next lesson.

Try this run and look at the result:

The card comes out just as pretty, but at the bottom it says Urgent False. The comparison priority == "high" has failed because the user wrote in upper case. And if they write superurgent, or leave the field blank by pressing Enter, the program does not complain either: it stores the rubbish and carries on.

That is exactly the work outstanding.

Forgetting the f of the f-string. print("There are {days} days left") prints the braces as they are. It does not raise an error, so you have to spot it in the output. If you see braces on screen, the f is missing.

Using double quotes inside an f-string delimited by double quotes. f"It is {x == "high"}" breaks the string. Use single quotes inside: f"It is {x == 'high'}".

Confusing .2f with "two digits". .2f is two decimals, not two figures in total. For the total width you use the number before the dot: {x:8.2f}.

Aligning numbers to the left. It comes out ragged and makes magnitudes hard to compare. Text to the left (<), numbers to the right (>).

Relying on \t to build tables. It works as long as every value is shorter than the tab stop; as soon as one goes over, the column shifts out of line. Use explicit widths.

Not assigning the result of input(). input("Name: ") without variable = in front asks for the data and discards it.

A prompt with no trailing space. input("Name:") makes what is typed stick to the message. Always leave a space.

Assuming that input() returns a number. It is the mistake that defines this lesson: it always returns a str. If you are going to calculate, you will have to convert.

Prompts that do not explain the options. If only three priorities are accepted, write them in the prompt. The cost of a clear prompt is zero and it saves half the wrong entries.

Tip: separate input, process and output. Look at the structure of this lesson's program: first all the input() calls, then all the calculations, and finally all the presentation. It is easier to read, to test and to modify than if they are all mixed together. This separation is a design principle that holds in programs of any size.

Tip: define the width as a constant. WIDTH = 46 instead of repeating 46 on fifteen lines. Changing the card's layout becomes a matter of one line.

Tip: test with awkward data. Run your program and type an extremely long title, or press Enter without writing anything. The card will go out of line or come out empty. Note down what you saw: that is what needs validating.

Write down exactly what each block prints, paying attention to spaces and line breaks.

Write a program team_summary.py that displays this table using only f-strings (no \t at all), with this data already written in variables:

Requirements:

• Header centred within a width of 44 characters, with lines of = above and below.
• Names aligned to the left; numbers to the right.
• Hours with one decimal; the load percentage shown as a percentage with one decimal (remember {x:.1%}).
• The total width must be in a constant and used on every line.

Write task_registration.py that:

1. Displays a welcome header.
2. Asks from the keyboard, with clear prompts: title, client, assignee and priority.
3. Displays a card with the four items lined up in two columns.
4. At the end, displays on a single line, using an f-string with an expression inside, whether the task is high priority.
5. Prints the type() of the priority variable and explains in a comment what the result means.

Solution 1.

a) Marta | Luis | Nuria — the sep replaces the space with " | ".

b)

A single line: the first print does not break because end=" -> ".

c)

.2f rounds to two decimals (7.456 → 7.46) and .0f to zero decimals (7.456 → 7).

d)

Ten characters of width in all three cases; what changes is where the text is placed. When centring with an odd amount of padding left over, the extra gap goes on the right.

e)

\n breaks the line and \t inserts a tab at the start of the second one.

f)

Without the f, the braces are literal text. It is the most common slip.

g) Total 1,250 — Total takes up 8 characters on the left, and 1250 is displayed with a thousands separator within 10 characters on the right.

Solution 2.

Output:

Notice the widths chosen: 14 + 8 + 11 + 11 = 44, exactly WIDTH. When the columns add up to the total width, the lines of = and - fit the table and the result looks deliberate, which is just what we are after.

Observe too that 9.25 with .1f is displayed as 9.2 and not as 9.3: faced with an exact tie, Python rounds to the nearest even digit (so-called banker's rounding). It is not an error, but it is worth knowing when you present figures to a client.

Solution 3.

Example run:

Try running it again writing HIGH for the priority: the card will come out just as correct, but High priority will still say False. That is the problem we solve next.

Your program now talks to the world. You know that print() accepts several arguments separated by commas — converting each one to text automatically — and that its sep and end parameters control what goes between the values and what goes at the end. You handle the escape characters \n, \t, \" and \\, and you know how to deal with quotes inside text in three different ways.

Above all, you have mastered f-strings: interpolating variables and expressions between braces, rounding decimals with .2f, and lining up columns with <, > and ^ to produce readable tables without depending on the tab. You also recognise .format() and the old % when you meet them in other people's code, even though you always write f-strings.

And you know input(): how it stops the program, how to give it a useful message and — the point that governs the next lesson — that it always returns a str, even when the user types a number.

EasyTask is at version 0.4 and already looks like a tool: Marta runs it, types the title, the description, the assignee and the priority of the job, and gets a lined-up card with the deadline and progress calculations. Nobody has to open the editor to register a new task.

But we have left two very visible loose ends. The first: the numeric data — estimated days, hours spent — is still written in the code, because what comes from input() is text and "3" + 1 gives a TypeError. The second: the program swallows anything the user types at it. If Marta writes HIGH, the comparison fails; if she writes superurgent, it is stored as it is; if she presses Enter without writing, the task is left with no title.

Both are the same problem seen in two ways: data coming from outside cannot be trusted. In Type Conversion and Validation you will learn to convert it to the right type with int(), float() and str(), to clean it up with .strip() and .lower() — which will at last make "HIGH" worth as much as "high", the loose end we left in lesson 01-05 — and to check that it is valid before using it. With that we will close module 2 and EasyTask will be, for the first time, a robust program.