01Brief02 / 08

The string built one piece at a time

build_query(params) turns a dict of parameters into a query string like "a=1&b=2". It works, and every case passes. Build it properly.

What is wrong with itIt grows the result with += inside a loop, then chops off the separator it added too many of. Strings cannot be changed in place, so every one of those += builds a whole new string and throws the previous one away.

Function	build_query()
Track	Making it better
Difficulty
Time	~15 min
Concepts	str.join immutable strings building versus appending
Cases	6

02The contract

Return key=value pairs joined by &, in the order the dict gives them.
Values are converted to strings — a number comes out as its digits.
An empty dict gives an empty string, with no stray separator.
Nothing is URL-encoded here; that is deliberately out of scope.

—The barchecked, not suggested

Build the pieces, then join them once. Repeated concatenation makes a brand new string on every pass of the loop.
Six lines including the def. Once join is doing the work there is nothing left to trim off the end and nothing to guard.

Every case still has to pass. These are checked by reading your code, so a solution that is merely correct will not clear them.

03Why this one

Almost everyone writes this version first, because it reads like what you would do with paper and glue. It is also the reason a report generator that was fine on a thousand rows takes minutes on a hundred thousand — and the trailing-separator fix at the end is a small ugliness that signals the shape is wrong. join is one of the few Python idioms worth learning purely because it deletes a class of bug rather than just a few lines.

—The concept behind it

Strings on pythonmastery.io →

That is the reading half. Read it there if the idea is new, then come back here — explanation is what makes something make sense, and practice is what makes it stay.

—Worth doing first

Initials from a name

Not a gate — start this one whenever you like. These cover ideas it leans on, and a tick means you have already done them.

your_code.py

05One way to write it

def build_query(params):
    return "&".join(f"{key}={value}" for key, value in params.items())

Three problems left at once

The quadratic copying, the trailing separator, and the guard that existed only to remove it — all gone, not fixed. That is the difference between refactoring and patching: the good version does not handle those cases better, it stops having them.

f-strings do the conversion, so str() disappears too

Anything inside {} in an f-string is converted to text automatically, which is why str(key) and str(params[key]) are not needed. Fewer conversions written by hand means fewer places to forget one.

items() beats subscripting in the loop

for key in params then params[key] performs a lookup you already had the answer to. items() hands you both halves at once — clearer, and one less operation per parameter. Small, and it is the same instinct as the lookup exercise: do not re-derive what you are already holding.

06When not to write this at all

Do not write this at all for real URLs. urllib.parse.urlencode handles the encoding this exercise skips — spaces, ampersands inside values, non-ASCII characters, and repeated keys — and getting that wrong is how you end up with a broken link or, in the wrong context, an injection. Also note += in a loop is genuinely fine for a handful of pieces; CPython even optimises some cases. Reach for join because it is clearer and has no trailing-separator bug, and treat the speed as a bonus.

07Take it further

Swap in urllib.parse.urlencode and compare the output for a value containing a space and an ampersand. Decide which differences matter.
Support a list value so {'tag': ['a', 'b']} becomes 'tag=a&tag=b', and note where the single join stops being enough.
Sort the keys behind an option, then argue with yourself about whether a stable URL for caching is worth losing the caller’s intended order.