Learn › Python for Linux Data and Automation › Make sample numbers meaningful

Calculate an honest sample report

Calculate sample capacity, available bytes and percent used; repair a misleading unit.

A number needs a meaning

Your Chapter 1 report displayed text you entered. This chapter adds calculations to the same manually entered sample inventory project. It still does not read the Linux guest. You need only Linux Foundations navigation and editing, plus Chapter 1's saved Python file, print, names and execution order.

The prepared working folder is ~/linuxcamp/python-inventory-02. Run cd ~/linuxcamp/python-inventory-02, pwd, and cat report.py. The copied project starts with two sample facts: capacity is 8589934592 bytes and used is 6442450944 bytes. A byte is a unit for an amount of data. We will calculate a report about those given amounts, not about this machine's disks.

Numeric values and text containing digits

Python treats 8 as an integer, a whole-number value. It treats "8" as a string, text whose character happens to look like a digit. The + operator adds numbers, but joins strings. The quotes in source decide which value Python receives. Consider these two calls:

print(8 + 2)
print("8" + "2")

hint: The first + has two numbers. The second has two pieces of text. >>> The first call displays the sum 10. The second joins the characters and displays 82. Text containing digits is not automatically a measured or calculated number.

To inspect real execution, type python3 in the terminal, enter those two calls one at a time, then type exit() to return to Bash. The >>> prompt belongs to Python's temporary interactive session. It is not part of a source file or an output line. Record what your own run displayed in observations.md.

When a known text value represents a whole number, int("8") produces the integer 8. Then int("8") + 2 produces 10. Conversion can fail for text that is not a valid whole number. Our sample byte counts are already integers, so the report does not need int.

Arithmetic keeps the units honest

The report uses - to subtract used bytes from capacity bytes. Both inputs are bytes, so capacity_bytes - used_bytes is also bytes: 2147483648 bytes available in this sample. The * operator multiplies. The / operator divides and produces a Python floating-point number, often called a float. For example, 6 / 8 * 100 evaluates left to right to 75.0. It represents 75 percent when the numerator and denominator use the same unit. A float may show a decimal point even when its value is a whole number.

Predict the available byte count and percentage before running the full report. Why does dividing used bytes by capacity bytes cancel the byte unit? Record your reason, not just the answer.

GiB and GB are different units

A gibibyte, written GiB, is 1024 * 1024 * 1024 bytes, or 1073741824 bytes. A gigabyte, written GB, is 1000 * 1000 * 1000 bytes, or 1000000000 bytes. They are both amounts of data, but the numbers differ. Dividing bytes by the GiB divisor gives a GiB count. Dividing by the GB divisor gives a GB count. Changing only the printed label cannot change a calculation's unit.

For this sample, 8589934592 / 1073741824 is 8.0 GiB. The same byte count divided by 1000000000 is 8.589934592 GB. Both calculations describe the same sample byte count, with different units. Neither is a live Linux measurement.

hint: Python calculates from the divisor. The quoted label is just text. >>> Python calculates 8.589934592 from the decimal divisor and prints the literal GiB text supplied by the source. The line looks precise but describes the wrong unit.

Inspect the saved report

The source's # lines are comments for the reader; Python does not display them. The report does not query a drive merely because the names mention capacity and used space.

available_bytes = capacity_bytes - used_bytes computes from the two sample facts. Each later / bytes_per_gib converts a byte amount. used_percent = used_bytes / capacity_bytes * 100 gives a percentage. The final call uses str(used_percent) to turn the numeric result into text, then + "%" joins the percent sign without an extra space. str changes how the number is presented, not the calculation or the source facts. Ordinary print with commas places spaces between its arguments.

Run python3 report.py. Compare its actual capacity, used, available and percentage lines with your predictions.

Compare the output with cat report.py. If you edited without saving, Python ran the saved bytes on disk, not the unsaved nano buffer. If Python reports an error, read the filename, line and message before changing anything.

Repair the unit mismatch

The report requirement is capacity, used and available amounts in GiB, with a used percentage. The given byte counts are correct sample facts. Keep them unchanged. Edit report.py with nano and correct the bytes_per_gib assignment to 1024 * 1024 * 1024. Save with Ctrl+O, confirm with Enter, exit with Ctrl+X, and inspect the saved line with cat report.py.

Before rerunning, predict all six output lines. Capacity should be 8.0 GiB, used 6.0 GiB, available 2.0 GiB, and used 75.0%. Explain why the percentage was already right in the first run even though the GiB conversion was wrong. Then run:

python3 report.py
python3 check.py

The first command is your real run. The formative checker executes a bounded copy of your saved source and compares the six requested lines. It cannot judge your reasoning or prove anything about this guest's storage. Record the output, the one-line repair and what remained unchanged in observations.md.

Test an explanation, not a label swap

What would happen if you kept the decimal divisor and changed only the GiB text to GB? That could make those three lines describe GB correctly, but it would not meet this exercise's GiB requirement. What would happen if you changed the input bytes instead? It would change the sample facts to fit a desired answer. The justified repair changes the unit conversion while preserving the given facts and percentage calculation.

The next chapters will keep related records and then repeat over them. This report remains a single authored sample until later lessons explicitly teach real Linux collection and its limits.

Return to a changed unit after Chapter 4

Return after Chapter 4 and other intervening study. Trying this immediately is useful practice, but record a later attempt separately with its date, interval and hints. The supplied later-case.py uses a new sample: 5368709120 capacity bytes and 2147483648 used bytes. A colleague now requests GB, not GiB. The saved file divides by 1024 * 1024 * 1024 while printing GB.

Predict its capacity and used percentage, then run python3 later-case.py. Explain which line is misleading and why. Correct the divisor for GB without changing the sample byte counts or the percentage rule. Save, rerun, and use python3 check.py --later. The corrected report should show 5.36870912 GB capacity, 2.147483648 GB used, 3.221225472 GB available and 40.0% used. Explain why this changed report has a different capacity number from 5.0 GiB even though the underlying byte count has not changed.

Record the first and second real outputs, your reason for the change, and any help used. The checker confirms output behavior for this sample. A later independent explanation remains separate evidence.

Practice Calculate an honest sample report in a real Linux terminal at The Linux Camp. Progress is verified automatically as you type commands on the machine.