🖨️ Displaying Output - Advanced

🖨️ Displaying Output - Advanced

The first Displaying Output lesson covered print(), sep, end and f-strings. This lesson is about the next problem: printing collections (lists, tuples, dictionaries, nested combinations of them) so the result is neat rather than a wall of brackets and quotes. The star of the show is str.join(), but it has several companions: unpacking with *, repr, dynamic field widths, pprint and json.dumps. The lesson finishes with a critical look at whether a loop like this belongs inline or in a function. As requested, the functions in this lesson are discussed in words only, and none of the examples define one.

🧰 The Toolbox

Ten tools, most of them one line long. The first three are about turning a collection into text; the rest are about making that text look good.

🔗 What join() Actually Does

Three facts explain almost everything about join.

1. The string you call it on is the glue. In " ~~~ ".join(value) the separator is " ~~~ ", and value is the thing being walked through. Python takes the first item, then for each remaining item adds the glue and then the item. The glue goes between items only. That is why join beats a hand-written loop with end=", ", which always leaves a stray separator after the last item.
2. It returns a new string and prints nothing. join only builds text, so you hand the result to print() or place it inside an f-string, exactly as the snippet does with {" ~~~ ".join(value)}. Because it builds the whole string in one go, it is also the efficient way to assemble text from many pieces, rather than += inside a loop.
3. Every item must be a string. A list of numbers, booleans or nested lists raises TypeError. The usual fix is ", ".join(str(item) for item in value), or the shorter ", ".join(map(str, value)). When the items are strings already, as in the snippet, you can pass the collection straight in.

When to reach for it: whenever you have a collection of pieces and want one line of text from them: a comma-separated list for a sentence or a CSV row, a path built from folder names, a multi-line block ("\n".join(lines)) printed with a single print(), or the contents of a list or tuple dropped into the middle of a label. When not to: if you only want the items on one line and they are not all strings, print(*items, sep=", ") is shorter and needs no conversion; and if the structure is nested, pprint or json.dumps will do the whole job for you.

✳️ The Star Alternative: print(*items)

print() already accepts any number of arguments, joins them with sep and converts each to a string. The * operator turns one collection into that many arguments, which gives you join's result without the string conversion step.

🔬 Dissecting the Snippet

Here is the code from the dictionary-iteration lesson again, piece by piece, followed by what it actually prints for a student record.

Where the snippet is fragile

1. A list of numbers crashes it. If "modules" were [101, 205], " ~~~ ".join(value) would raise TypeError. It works here only because every list and tuple happens to hold strings.
2. The else branch quotes numbers and booleans. 21 and True print as "21" and "True", so a number looks like a string.
3. It goes exactly one level deep. A list inside the inner dictionary would print in raw bracket form, because the inner loop has no type checks of its own. Handling it means copying the whole if / elif chain inside the inner loop, and then again inside that.
4. Every line ends with a comma, including the last. It looks like JSON but is not valid JSON.

None of this matters for a classroom exercise. All four are exactly the kind of thing that starts to matter when the code has to cope with other dictionaries, which brings us to the reason for the next two examples and the function discussion after them.

♻️ The Same Pattern, Different Data

The structure is identical (.items(), an isinstance chain, a nested loop) but this version fixes the fragile points: it converts list items with str(), merges lists and tuples into one branch, drops the quotes, and aligns the keys in a column.

🪄 Letting the Standard Library Do It

If the aim is just to look at a nested structure, the loop above is more work than needed. pprint and json.dumps handle any depth and any mix of types.

📏 Case Study: A Dictionary as an Aligned Table

Dynamic field widths and the extra format specs together: the column width comes from the data itself, so adding a longer name later never breaks the layout.

🧩 A Critical Look: Loop Inline, or in a Function?

The idea: instead of repeating the isinstance chain, write a function that receives the data, works out each value's type and prints it appropriately. Functions come later in the course, so this section describes the design in words only. Your instinct is sound, but how sound depends on the situation.

What the function would look like

It is worth being precise about the design, because the version you described has a choice in it. You said you would pass over the key and value, then wondered whether passing the whole dictionary is better. It is, for most purposes. If the caller passes one pair at a time, the caller still has to write the for key, value in ... .items() loop each time; only the type chain has moved. If the caller passes the dictionary, the function owns the loop too, and the calling code collapses to one line per dictionary. Passing a single pair only wins when you want to print a handful of selected entries, or in a different order.

There are two further refinements worth knowing about. A function that returns the text instead of printing it is more flexible, because the caller decides whether to print it, save it to a file or check it. And a function that receives a dictionary can, for a nested dictionary, call itself on the inner one. That is something an inline loop cannot do: it can only handle as many levels as you physically copy the code for.

Which is better, and when

One more critical point. A growing if / elif chain that tests types is, in Python terms, slightly against the grain: Python usually prefers asking an object to do something rather than asking what it is. For display code that is accepted, because the alternative (making each type print itself) is more machinery than the job deserves. If the chain keeps growing past four or five types, though, that is the sign to stop and ask whether pprint or json.dumps already does it.

📋 Quick Reference — Advanced Output