01Brief01 / 12

How the answers split, as a percentage

label_share(answers) takes a Series of survey answers and returns the breakdown: each distinct answer, how many times it was given, and what share of the total that is. Most common first.

Function	label_share()
Track	Tables with pandas
Difficulty
Time	~20 min
Concepts	value_counts normalize for proportions ties need an explicit order
Cases	9
Needs	pandas about 9 MB, because pandas brings numpy with it, fetched once and then cached by your browser

02The contract

Return a list of dicts with exactly the keys 'label', 'count' and 'share'.
'count' is a plain int; 'share' is the proportion of all answers, rounded to 4 places.
Rows are ordered by count descending, and by label ascending where two counts tie.
Every distinct answer appears exactly once.
An empty Series gives an empty list.
The caller’s Series is not modified.

03Why this one

Counting how often each value appears is the first thing anybody does to a new column, and value_counts does it in one call — sorted, descending, ready to read. The two things it does not do are the two things a report needs: it makes no promise about the order of values that tie, and its counts are counts rather than shares. Both are one keyword or one line away, and both are easy to leave out.

—The concept behind it

Dictionaries 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.

—What this leads to

A row-by-row loop over a table

These build on what you are about to write here.

04Study first: what value_counts gives you, and what it does not

One call does most of the work. Look closely at the two ties, and at what the index is.

import pandas as pd
answers = pd.Series(['b', 'a', 'b', 'a', 'c'])

answers.value_counts()
# b    2
# a    2
# c    1        sorted by count, descending — and b before a, because b
#               was met first. Not alphabetical, and not a promise.

answers.value_counts(normalize=True)
# b    0.4
# a    0.4
# c    0.2      the same thing as proportions of the total

# The labels are the *index* of the result, not a column:
counts = answers.value_counts()
list(counts.index)      # -> ['b', 'a', 'c']
counts['a']             # -> 2

# And the two-step sort that pins the tie order down:
counts.sort_index().sort_values(ascending=False, kind='stable')
# a    2
# b    2
# c    1        alphabetical within each count

value_counts sorts by count, and leaves ties to chance
Two labels with the same count come out in whatever order the counting happened to produce, which depends on the data rather than on any rule. So a report built straight off value_counts is stable until the day two options draw level, and then it reorders itself for no visible reason. If the order matters to a reader, it has to be stated.
Sort by the tiebreaker first, then by the thing you actually want
counts.sort_index() puts the labels in alphabetical order; sort_values(ascending=False, kind='stable') then reorders by count while leaving equal counts in the order they were already in. Sorting least significant key first and relying on stability is the general trick for ordering by several keys — the same reason kind='stable' exists at all.
The labels are the index, which is why to_dict and .index both come up
value_counts returns a Series whose index is the distinct values and whose values are the counts. That is convenient for a lookup (counts['a']) and slightly awkward for a report, which wants the label as a field — hence .items(), or .reset_index(), or a comprehension over .index. All three are fine; knowing that the label lives in the index is what stops the confusion.

your_code.py

05One way to write it

import pandas as pd


def label_share(answers):
    counts = answers.value_counts()

    # Alphabetical first, then by count descending with a stable sort: equal
    # counts keep the alphabetical order, which is the documented tiebreak.
    counts = counts.sort_index().sort_values(ascending=False, kind="stable")

    total = len(answers)

    report = []
    for label, count in counts.items():
        # int() once, and then the division is ordinary Python arithmetic:
        # an int over an int gives a plain float, not a numpy one.
        count = int(count)
        report.append(
            {
                "label": label,
                "count": count,
                "share": round(count / total, 4),
            }
        )
    return report

Two sorts, least significant first

This is how you sort by several keys when the tool only takes one at a time: order by the tiebreaker, then by the primary key with a stable sort, which leaves the earlier ordering intact wherever the primary key is equal. It generalises to any number of keys, in reverse order of importance, and it is worth recognising because you will meet it in shell pipelines and SQL-free reports for the rest of your life.

One denominator, computed once

value_counts(normalize=True) would also give the shares, at the cost of a second pass over the data and a second Series to keep aligned with the first. len(answers) is the same number, available for free, and it makes the division visible on the line where it happens — which matters when somebody later asks whether the share is of all rows or only of the answered ones.

int(count) is insurance, and it depends on how you got the count

Series.items() already hands back plain Python scalars, so the int() here changes nothing today — it documents the boundary and survives a rewrite. What does leak numpy’s int64 is .values, .iloc and .at, which hand you the stored value untouched; and an int64 compares equal to an int, prints like an int, and raises TypeError the first time json.dumps sees one. Converting before the division matters for the same reason: int64 / int gives a float64, and round() on a float64 gives another float64.

06When not to write this at all

If the column has missing values, this counts around them: value_counts drops NaN by default, so the shares would be of the answered rows while len(answers) counts all of them — and the shares would quietly sum to less than one. Decide which you mean and say it: value_counts(dropna=False) to make 'no answer' a row in the report, or answers.dropna() as the denominator to make the shares proportions of the answered. The bug is having one of each. And if the output is heading straight into another frame rather than to a caller who wants dicts, stop at the sort — reset_index() gives you a two-column frame and the list of dicts is a round trip you did not need.

07Take it further

Add a cumulative share, so a reader can see how many labels cover 90% of the answers.
Take a top_n argument and roll everything past it into a single 'other' row whose count and share still make the totals reconcile.
Handle a Series with missing values, and make the choice from 'when not to' an argument.