0%

The Standard Library Exists · practice

Order Output on Purpose

The three library-backed return stable facts, but presentation adds one more decision. Counter remembers the order in which it first encounters each category. These inputs therefore produce equivalent counts with different key orders:

first = [walk_record, read_record]
second = [read_record, walk_record]

A report that follows encounter order changes when the records are rearranged. That makes tests, comparisons, and later saved data needlessly noisy.

Sort a separate list

Build a of Counter’s category keys, then call its .sort() . With no , .sort() rearranges the list itself into natural order: become alphabetical here.

The part that catches people is what .sort() hands back:

Try it

The sorted list is names. The method returns None, so assigning that and trying to over it is a common mistake.

Do not try to sort the Counter in place. Build a separate name list, sort it, then format name=count pieces in that order. Counting and presentation stay as separate jobs.

After names.sort(), where is the alphabetical result?

Test this the direct way: shuffle the records by hand into a different order, call the formatter twice, and confirm both calls return the same line. If the line changes when the input order changes, the sort is not doing its job.

Task

Implement format_category_counts(records) in activity_report.py.

  1. Call count_categories(records).

  2. Build a separate containing every category key in the Counter.

  3. Call .sort() on that list.

  4. Build name=count pieces in the sorted order.

  5. Return the pieces joined by , .

For an empty record list, return the empty naturally. Do not hard-code the sample categories or rely on record encounter order.