Text parsing and characters without hidden assumptions

By UK GCSE Computer Science · independent study · myAudience

Original AI-generated teaching raster via built-in image_gen; author inspected 2026-10-04. · Generated project artwork; no copied exam or publisher illustration. Independent rights/publication review pending.

Text parsing and characters without hidden assumptions

Strings are sequences of characters used as text, not interchangeable with stored numeric quantities. len(text) reports the Python sequence length, text[i] selects one position and text[start:stop] produces a substring excluding stop. Concatenation with + joins text. The original input format here is exactly two uppercase ASCII letters, a hyphen and three ASCII digits, such as AB-007. Entry skills are indexed lists, comparisons and whole-number conversion. The declared alphabet matters: Python's isdigit() accepts some non-ASCII digit characters, so it does not on its own enforce this particular format.

Parsing translates a representation into structured meaning. First check overall length and the delimiter at position 2. Next check membership of each letter and digit in the permitted alphabets. Only after these checks do we convert the suffix to an integer. Leading zeroes are preserved in the original identifier but disappear from the integer value: AB-007 gives the prefix AB and number 7. If the number is later displayed in a three-digit field, formatting must restore that width deliberately. Silently treating the entire identifier as a number would lose its prefix and identity.

A character set assigns codes to characters. Seven-bit ASCII has 128 possible codes; capital A is 65, B is 66 and so on within that group. The sequence does not imply every character grouping has no gaps. Unicode supports a much wider repertoire and shares ASCII code points through 127. Python ord('A') is 65 and chr(65) is 'A'. A code point is not a file byte count. Our UTF-8 illustration below is an extension beyond the specification's required encoding variants: 'é' has code point 233 and one Python character but uses two UTF-8 bytes. Even len(text) need not count user-perceived symbols when combining marks are involved.

The parser is a pure boundary routine and returns a pair only on successful validation. It raises ValueError for an incorrect format. It does not check whether an identifier has actually been issued, which would require an external authoritative list. Validation and verification are therefore distinct. The runnable test with an Arabic-Indic digit guards the declared ASCII contract without using personal data. Another contract could intentionally accept more alphabets, but it would need a defined normalisation and identity policy rather than accidental acceptance.

The binary raster supports the idea that stored codes have bit patterns but does not contain a character table. Use the prose and a given table when decoding. The transfer task changes both the accepted format and the handling of leading zeroes; it asks for a deliberate parsing algorithm instead of guessing from slicing. Real user-facing identifiers also raise accessibility questions about confusing glyphs, but the toy format is not evidence of a usable or secure authentication system.

Runnable original Python 3 example (also saved verbatim in examples for CLI execution):
```python
def parse_tag(text):
"""Parse exactly AA-000 style ASCII text into (prefix, number)."""
if len(text) != 6 or text[2] != "-":
raise ValueError("tag shape")
if any(ch not in "ABCDEFGHIJKLMNOPQRSTUVWXYZ" for ch in text[:2]):
raise ValueError("tag letters")
if any(ch not in "0123456789" for ch in text[3:]):
raise ValueError("tag digits")
return text[:2], int(text[3:])

assert parse_tag("AB-007") == ("AB", 7)
assert ord("A") == 65 and chr(66) == "B"
assert len("é") == 1 and len("é".encode("utf-8")) == 2
try:
parse_tag("AB-٠07")
except ValueError:
pass
else:
raise AssertionError("non-ASCII digit was accepted")
```

Worked example: Decode ASCII codes 67,65,66 and explain why AB-007 cannot simply be converted to one integer.

From A=65, code 67 is C and code 66 is B.

The decoded string is CAB.

AB-007 contains a letter prefix and delimiter; its numeric suffix has value 7 but the complete identifier is text.

Answer: CAB; parse the structure before converting the suffix.

Check your understanding: Transfer: tags may now have one to four letters and one to three digits, separated by exactly one hyphen. Design validation and give three discriminating erroneous tests. State whether AB-7 and AB-007 identify the same thing.

Answer: Split on the hyphen and require exactly two parts; require 1..4 uppercase ASCII letters and 1..3 ASCII digits. Reject A--7, ABCDE-7 and AB-1234 for distinct reasons. Their numeric values agree, but identifier equivalence must be specified; preserving the raw suffix treats them as different.

Why: Fixed-position slicing no longer works because prefix length varies. A correct answer must enforce both part counts and length bounds. Numeric equivalence is insufficient to infer identity, and normalisation can merge records unintentionally.